I think Teensy can handle al the IO and communicate via usb?
Yes, I’m using a teensy for a way more complex midi controller, but honestly for four encoders, nothing more than an MCP23017 is required.
Is the goal to simplify wiring or have more elaborate on box controls?
Thanks to all for answering and letting share their ideas!
Yes - this will be an option. But having to support a software on different smart-phones is absolutely out of my scope 
Also I am not sure if this can be really used live on stage.
This should not be a show-stopper. In fact you won’t really use a stack of more than two or three hats. This has side-effects to the cases - perhaps a standard case does not fit anymore. Anyway for my PiSound card the standard case will not fit due to the MIDI connectors on the board.
I think simplify wiring is the way to spread Zynthian over the world. For more controllers there are several additional options (MIDI, uC/USB, …). The goal should be to have a well defined system which is easy to build and use. For me: Fernandos standard design with four encoders, soundcard and a display.
What I have identified in this discussion:
- Stage/live compatibility?
- Is compatibility to a case important?
- Is external hardware needed or should a smartphone/tablet (optional) be used as controller?
- Is an expansible controller system necessary or only the four /standard) encoders?
- Is the goal to simplify wiring or have more elaborate on box controls?
The MCP23017-hat seems to be a very nice toy! But you still have to create a set of cables for the encoders and you have to solder the MIDI input opto (also if using a uC for encoder-controlling).
Will a dedicated “all-in-one” PCB the best solution? I have something like a hat in my mind. One PCB with direct soldered encoders and MCP23017 plus MIDI opto. Only one ribbon cable to the Raspi and a cable for the MIDI connector… But one “big” PCB is a limitation for some cases or displays…and how to produce this PCB (Kickstarter?) very much problems… difficult to solve…
Regards, Holger
1 Like
I’m an electronics engineer and can make a board. I’d avoid the Kickstarter approach since the expectations of backers would be high. If the campaign was a success, then someone could be soldering hundreds of boards. It would be easier to publish the gerber files so people can order boards locally or from China. I haven’t looked into it, but some China manufacturers (like Seeedstudio) offer packages with component sourcing & assembly.
I think that the biggest challenge is defining what is needed. I like the idea of a single PCB with the encoders & other logic on it. But there are many Zynthian variants out there with different screen sizes so having separate encoder boards makes sense.
Making a HID class compliant USB controller is straightforward with the right Arduino (Micro?). But then the USB port would be blocked.
As Johnny Nash sang…“There Are More Questions Than Answers”
1 Like
The basic interface is built around four encoders and a flat screen, but I would suggest a lower level option.
A pure hifiberry amp or hiberry DAC+ in a hifiberry case with an external USB driven 4 knob box, and an HDMI touch screen.
You loose two usb connectors certainly but the only self build component is the usb connected ( & powered) knob interface box. It separates the interface from the device.
It allows me to place my hifiberry amp on the floor driving the speakers and the USB control interface a usb cable away on the mic stand with a hdmi screen somewhere, I don’t even need it to be touchscreen, loosing only xy control.
Simple, easy to transport to gigs and means you keep Ethernet, HDMI, Power connections and audio signals or speakers off the stage. but give a user an awful lot of power in a very neat contraption.
Plus we have an easy to use approach to the encoder issue that pushes hardware-software crossover into a much less core functionality. The hobbyist is more empowered.
Just thinking . . .
2 Likes
@C0d3man :After reading @beckdac topic about jack2midi … maybe using a game pad like a xbox or PS controller (a standard Item many people have around anyway) as a makeshift easy to use default input device is an great idea! This might help people to get a easy first entrance into the zynthian world.
Of cause that would not be integrated into the case but as soon as someone likes the zynthian that way is open for a more serious approach.
2 Likes
Stop reading my mind! 
This is exactly what I was trying to figure out.
1 Like
The other bonus is that there are a bunch of bluetooth based “joy” devices which would not require any wires or power.
Do we have a MIDI sysex code and suggested protocol for remote control via MIDI?
0xF0 xx
encode 1 left 0x00
encoder 1 right 0x01
encoder 1 switch 0x02
encoder 2 left 0x10
encoder 2 right 0x11
encoder 2 switch 0x12
encode 3 left 0x10
encoder 3 right 0x11
encoder 3 switch 0x12
encoder 4 left 0x10
encoder 4 right 0x11
encoder switch 0x12
sort of thing . . .
Hi all,
I think we have to differ the different approaches. And we should have in mind, what Zynthian should be. My personal point of view:
- a dedicated music instrument (black box - no idea of what is inside) stable and usable on stage
- easy to use and build
A game-controller might be a nice thing for controlling - but nothing for a real instrument on stage. Don’t misunderstand: I like the ideas! All ideas mentioned are really good - but IMHO as a 2nd way to control a Zynthian.
So I think there are three groups of interested users (a user might be in more than one group):
- Musicians
- wants to use a stable instrument on stage
- need reliable hardware (and software
) - has money
- Maker
- want to tweak the system
- likes to build from scratch
- don’t fear solder irons
- Fun-User
- likes the idea of open source synth
- won’t invest much money
- won’t solder PCBs
And we have currently the following ideas:
- Standard encoder/MIDI PCBs (as the current ones: solder by yourself)
- PCBs with preinstalled hardware (e.g. Seeedstudio) and connection via USB
- uC based (Arduino, Teensy)
- MIDI compatible (sysex)
- OSC compatible
- own protocol
- uC based (Arduino, Teensy)
- Game-controller (PS, XBox, “BT”)
So there should be three ways for building a Zynthian:
- Standard controller for Makers
- Easy controllers (Game controller) for Fun-Users
- Prebuild controllers (uC) for Musicians
For 2.) “only” programming is needed. For 3.) a hardwaredesign and programming is needed.
Ok - stopping here to give time for disassemble my ideas 
Regards, Holger
1 Like
I think you have missed a group of users.
Roadies or Keyboard Assistants, Assistant Stage Managers, Mixing Engineers … all kinds of names
basically people who are not performing but are technically adept enough to install and operate stage related equipment . . .
Roadies
wants to use a stable equipment on and off stage
need reliable hardware (and software )
has No money
don’t fear solder irons
These people can often be found building the stage kit, mixing the pa, providing foldback mix, panicking on talkback, loading up samples and patches for on-stage musicians, stripping it all down and humping it out at the end of the night…
They are REAL experts on connectors…
They are the real users of swiss army knifes , ( and gaffa tape…)
ON their behalf I would ruthlessly reduce the numbers of cables on stage in any system and beef up the connectors to something you could take on military maneuvers .
1 Like
==> More or less also makers 
perhaps they drink more beer 
It’s the ruggedising that probably differentiates the two:
A Maker knows the idiosyncrasies of their own kit but may not understand the implications of stage use, thank god the Internet never got a picture of the first synth I built 
The first time I plugged it in on stage it took out the Residual Current Device simply because they were a fairly rare device back then (1979) Earth/Neutral Short, and I knew no better.
I also witnessed an early testing of a drum synth, nice electronics but it lasted about two minutes with a fairly light fingered drummer cos all the mountings were anchored in plastic …
Sorry to bore with nostalgia, but a roadie will point you at use cases that often the musician doesn’t really appreciate.
I still see people turning up at open mic nights with kit in the original cardboard boxes, and wonder why after a couple of wire trips wonder why the input jacks crackle, and who are surprised by quite where the final volume control should be. . .
Also Stage Assistants tend to be the people who play in the effects, click tracks, backing tracks and set up the patches for theatrical performances and I see the zynthian as eminently suitable for that kind of use.
Sound effects for stage performance become so easy with fluidsynth for instance.
I will shut up now . . .
1 Like
Okay, but it would be interesting if the API you develop allows developers to do this kind of work.
I saw something similar using “Control Chain” of MOD Devices. One developer ported the Control Chain client protocol to ESP8266, connected an iPad into ESP, developed a program for the iPad and controlled the MOD Duo with the iPad.
In Raspberry you would not need ESP8266 or Control Chain protocol, just that a library has a way to control the equipment.
So if you decide to develop a protocol for controls Zynthian with Arduino over serial with USB, allow the solution to be encapsulated so that a developer can use this protocol via Bluetooth, http, or even make the protocol API functions accessible (documented and tested) so that developers can directly use this API
I know the thread in the MOD forum and ContolChain (I also have an Arduino shield for ControlChain but no time for testing/using).
Of course, the protocol/API should be protable and open! But for now the the goal is to find a good way how to make the creation of Zynthian easier…
Regards, Holger
1 Like
Hi all,
I have read the different posts and i think it’s indeed a very good idea to see if some of RPi’s handling overhead like GPIO to an external device / Mirocontroller. The advantages are obvious öike more “free” pins on the RPi and (maybe?) improved latency - if that is still considered a major concern also more functionality.
Major problem will be to discuss (see what’s already presented) and then decide on a durable modification which would also allow more devices to be added in the future without turning the existing completely upside down - that wouild indeedf frighten away other new (“world-wide”) users.
This leads to the proposal to focus on existing bus structures like I2C or SPI, CAN or else, for which basic knowhow is around not mmaking it necessary to develop everything from sratch. As one hardware candidate I’d like to propose something like Teensy 3.2 or 3.5 which by far outperform the arduino family, and they also have other advantages like tolerating 5V input etc. However, other mothers also have beautiful daughters ;-))
If can be of any help as a bloddy beginner, I’d be glad to participate, especially when my first ZBox (Standard) is up and running (will send some comments about that in the next few days).
My explicit wish would be to make a quite general hard- and software expansion with best computing power which would allow easy addition of things like Jofemodo’s encoder to MIDI develoquitepment (why only MIDI?), breath controllers and the like. BTW, has anyone already inpected solutions like “Virtual GPIO PC” for those for which even RPi3 is not powerful enough ?
So, be is as it is, ZBox development remains to be a very exciting project,
CONGRATULATION !!!
Hi Zynthianiacs,
the following ideas are in my mind:
- External game controller (easy for new users)
- ToDo: extend Zyncoder library to support this - not really easy…
- External uC controller via USB-serial protocol (modular way, for normal makers)
- ToDo; specify protocol, extend Zyncoder library
- Raspi-shield/hat with MCP23017 (=“encoder interface”) and MIDI (In/Out/Thru) and seperate Encoder PCBs - (perhaps all pre-built)
- much more difficult to build, but perhaps an option if it can be ordered/manufactured by a specialized company
- in fact this is nothing else than the current designs, but if can be ordered pre-build, only plug and play should be necessary.
For 3.) my thoughts are going to a shield where the encoder pins are plugs on the shield an you only have to connect the encoders (like Ebay Rotary Encoder on PCB).
Only my thoughts…
Regards, Holger
1 Like
Hi Zynth addicts,
as usual C0d3man has given us a pretty clear structured way forward!
just want to add:
re 1) there are already many descriptions for adding game controllers, you can find them with google “game controller for arduino”, “game controller for teensy” and so on, so implementing this does not need to start from scratch…
re 2) maybe for best useability, this option could use a staged approach for the introduced new mikrocontroller, like:
… time-critical response: use interrupt drivers for input and for reactin just as well
… less time critical: use a mix of polling and interrupt
… not time critical: use polling only
re 3) this option could also supply some storage area where the selected parameters can be stored in like a buffer which could then be read by other RPi programs. This would then mean to implement some memory and logical (I2C or SPI?) access structure on the extension interface which can be assessed by the RPi…
Another question to solve is definition of a min/max number of GPIO pins which could then lead to the decision how many MCP23017 ports should be used or if ports e.g. on a Teensy 3.5 could be sufficient (and maybe also expandable later) …
A reasonable starting point for “2” and/or “3” could be a durable definition of exactly how MCP or Microcontroller (preferred?) can be implemented . If such protocol is agreed on, then there are many open options about how port expanders or other mikrocontrollers should be connected to RPi without too many changes to existing RPi software …
Again, just some humble thoughts for best possible solutions…
Hi all,
just for thinking I would add a 4. option:
The Rpi3 has just enough GPIO-s for all the 4 encoders and buttons, so You don’t need any port extender HW, like the MCP23xxx. My box works this way. This thought is for the “Encoders via GPIO” part of the topic title.
Regards Norbim