Hi all,
I just thought about connecting more controllers. I will try to use an Arduino with some buttons and encoders. Also I want to use the MIDI-Controllers from my Master-Keyboard. It would be nice to have some kind of (existing?) protocol as a standard for connecting all kind of controller - perhaps self configuring?
Just these few lines for starting a discussion…
Regards, Holger
Hello C0d3man,
I have only now stumbled over this post and maybe my abolutely smart comments are already obsolete, but since this has a close connection to the more recent GPIO / MIDI discussions …
So I have included my more recent collection on MIDI controllers - see als a few comments underneath …
001 - https://www.arduino.cc/en/Tutorial/Midi
002 - http://www.instructables.com/id/Send-and-Receive-MIDI-with-Arduino/
003 - http://www.instructables.com/id/Custom-Arduino-MIDI-Controller/
004 - https://learn.sparkfun.com/tutorials/midi-tutorial/all
005 - http://www.makeuseof.com/tag/make-midi-controller-arduino/
006 - https://www.midi.org/articles/arduino-midi-output-basics
007 - check “a-curated-list-of-midi-diy-projects” on
https://www.midi.org/articles/
008 - http://libremusicproduction.com/tutorials/arduino-and-midi-out
009 - https://www.tigoe.com/pcomp/code/communication/midi/
010 - https://en.wikipedia.org/wiki/MIDI
011 - https://diymidicontroller.com/diy-midi-controllers/arduino-midi-clock-…
012 - https://uu.diva-portal.org/smash/get/diva2:1058266/FULLTEXT01.pdf
013 - https://quod.lib.umich.edu/cgi/p/pod/dod-idx/airduino-an-inexpensive-d…
014 - http://www.synthtopia.com/content/2014/11/25/arduino-midi-bluetooth-so…
015 - https://shanteacontrols.wordpress.com/
016 - https://arduino.stackexchange.com/questions/3219/sending-midi-messages…
Also take a look at https://midikits.net/ for midi trumpet & trombone plus some other controllers
and have a look at:
(PDF) MusicXML 3.0 Tutorial
… https://wpmedia.musicxml.com/wp-content/uploads/2012/12/musicxml-tutor…
and also check : (PDF) MIDI Toolbox - Music-IR.org
… http://www.music-ir.org/nema_out/mirex_debug/JSSLP/midi_tool_box_manua…
and if someone wants to dig deeper into how “realistic” instruments could be designed, there is also a lot of material like at http://acoustics.ippt.pan.pl - in english ;-)))
worthwhile to mention is also a toolbox called “virtual GPIO for PC”, where the author describes exe code
which will run both on a PC via USB as well as - without changes or re-compiles - also on RPi. This seems to take can free quite some computing power from RPi by distributing tasks to Arduino slaves, which has nothing else to do but interpreting GPIO commands and process them too.
now to some questions to discuss in addition to the models 1,2,3 which you have already proposed, i.e.
1 - what type of MIDI information shall be constructed and passed on to the sound-production softwares?
… note on / off, velocity etc ???
… other controller messages (Most already pre-defined, (like e.g Microtuning) ???
… sysex messages - which most open opportunities,
(pro:) because the Zynthian Project could define here anything they want;
(con:) thereby on the other hand not always being compatible with the different sound production programs …
2 - Do you think that all parameter changes should then be passed on to the RPi , or could we not
devise some sort of streaming / ring buffer which RPi can read whenever there is need ? This second option
could help to remain at a more clear layer struture like you also have in the IP protocol, so there is less
chance that each new controller added could create unforeseen other difficlties coming from too compley a system …
OK, once again jsut a few humble thoughts where I do not have a clear visiion where this fine project will have its
touch down - so tell me what you think about all this …
regards, Tom
I see the zynthian simply as another midi instrument like the ones it is hosting.
Thats why we are about to introduce the master channel and midi filters for the volume or program change.
Additionally it will be able to catch internal or external button events from those various sources (GPIO, USB) and generate Midi CC (OCC, et.al ?) commands (freely configurable) , so that you are able to control the hosted linux devices as well as external MIDI devices (when we have MIDI out).
Hi Tom,
thanks for your list of links! I will check them at night… currently I have not much time.
Just one word to MIDI and Zynthian:
We have to differ between using MIDI controllers and how to control the Zynthian-GUI! The hardware encoders can be used as MIDI controllers for engines/plugins - right. And using MIDI-CC / MIDI-PC for callings setups et. is also important. But the initial idea was to use alternatives for the encoder-hardware. If and how they are mapped to MIDI-CC/… is IMHO part of the zyncoder library (as it is currently used for creating MIDI/OSV messages).
I think using MIDI messages for controlling the Zynthian-GUI would be very problematic: Think about how to map MIDI values (0…127) to messages from endless-encoders (right/left)…
Regards, Holger
Hello again - and thanks for clarification(s) !!
trying to be shorter than ever:
… has anyone thought of including a little hexadecimal keypad in combination with those endless controllers? that could help a lot in organizing some controller hierarchy and would be pretty easy to implement just like in the old day …
regards,Tom
Conceptually it seems a little late to introduce an entire new interface component, unless it first exists as a purely virtual component within the current touchscreen component and then you are requiring it for a non touchscreen implementation!
That’s not to say it’s not a useful component in concept but I would support a full alphanumeric keyboard because, personally, I’ve always found the process of naming patches or samples or anything really, using only a press button or rotary encoders very unwieldy, which leads to lots of files with short names or nunbers rather than the more useful description a full text input can give you.
We have usb ports: A keyboard is an easy component to add and most people would have one to hand, which would not be true of an alphanumeric.
A possible solution to the MIDI controller mapping would be to use an absolute position from the control to use a hook like mechanism and then provide a rotation dependent stream of pulses; left of centre to decrease, right of centre to increase, like a pitchbend.
. So four controller pots would map to the four zynthian controllers. Position the pots in thier central controller position (64) would correspond to no encoder pulses, with a dead band either side 59 - 70 which produces one encoder pulse per two seconds, so you would twist the pot around the 64 position to move back and forward, further movement away from the central position would increase the rate of encoder pulses, hense speed of movement thro’ the menus’ ( a possible issue with the size of number of options there might be. . .
The initial set up would simply involve the controller turning the pot till it got to 64 in which case the interface would ‘start’. If we could get some element of visual feedback to indicate when an pot controller had hooked up that would be nice but probably isn’t essential.
I would expect people to map 4 specific pot controller to purely operate the zynthian so they would quickly adjust to the 64 position . . .
The encoder switch would work for specific keys mapped from a MIDI keyboard, another device that one could reasonably expect to be connected to the zynthian, and we have a fairly major handle on the MIDI stream 
One completely virtualized control interface 
You can throttle the encoder readings (every few ms or if change is greather than 60) and send a value “x”.
Something like:
x = 64 : knob click
x < 64 : (64 - x) is subtracted from the “current” parameter value
x > 64 : (x - 63) is added to the “current” parameter value
Been there, done that… a looong time ago, when “7E1” was quite normal on serial communications 