Using MIDI controllers instead of Encoders

So the section of the Configuration guide which has the same title as this post basically says “it’s too hard to use a midi controller because it doesn’t have the right controllers. Why not use a keyboard or mouse instead?”

What if someone (me) just built themselves a midi controller with specifically the right controllers? Shouldn’t you really have a midi implementation available that people can make their own informed choices about whether they are able to implement it in their hardware? Cause I have the right encoders and the right buttons and everything, and I can literally make them send any CC you like on any channel you like. There should be a list of CCs and values for me to map these to on the site.


Have you read the wiki entry entitled, “Controlling the UI with MIDI messages” here? It shows the MIDI messages that can be sent on the “master channel” to control the Zynthian.


Ahh, there it is! I have no idea why I have not been able to find it during various episodes of browsing today. sorry for snark, I was about to explore reimplementing the teensy’s usb midi controller into an i2c controller.

1 Like

Notes instead of CCs eh? Interesting implementation. ;->

1 Like

Yep! There was a technician challenge that limited it to notes. I think there is a comment in the docs saying it might be expanded in the future but that hasn’t yet happened. That same comment suggested using a MIDI filter to translate commands if required.

1 Like

It would be fine, really, if not for the fact that the real interface uses timing of button presses, whereas this just accepts different notes to represent that subtle user action.

So rather than just assign CCs for each controller action and button and let the zynth do its thing, I’m gonna have to write code to time my button presses myself, so I can send a dumbed-down message which will get turned back into what I actually did.

I guess I can always wire them to the Pi directly, but I’m assuming that will kill any possibility of using this as a general purpose set of midi controls? Or does Zynthian at least send the controls as CCs?

Would you happen to know which repo/file has the code for this master channel, and which has the timing routines for the buttons?

If you are on testing branch, you can edit the action that is triggered for every note.
Check the new Master Key Action editor at the end of webconf’s MIDI Options panel:



I still have to write C code to duplicate your button behavior - instead of implementing your short/bold/long timing in midi, you split [four buttons] into [twelve buttons]. In order to make it work as it’s supposed to, I’m gonna have to duplicate your code in the Teensy so I can send you the right notes, which the Zynth will then have to reconvert back.

I’m gonna have a go at extending the MidiController teensy library - he’s already got several button behaviors available so I’m gonna try to add a Zynthian behavior. I wish I was a better programmer, I would just add proper handling of CC buttons in, but I’m not very good at C, yet.

Hallo @jtode,
you can also use OSC commands so can build OSCcontroller. :slight_smile:

1 Like

I also would choose OSC instead of MIDI for this.
Anyway, take a closer look to the CUIA list. You don’t need to emulate bold/long pushes, simply call the right CUIA :wink:


1 Like

But what do I do on my midi controller, which has four encoders with switches on it, to trigger those CUIA actions? Put in eight more buttons? I’m not understanding how I duplicate the standard Zynthian UX on my bespoke controller without programming your switch behavior into it.

In order to trigger a bold press of the top left encoder, I intend to do a bold press of the top left encoder. That’s how you designed it to work, right?

*also, as previously noted, this is intended to double as a general purpose midi device - the bottom four buttons are stomp switches for that reason. I actually have some fairly complex configurations planned, based on midi to control midi devices, so unless OSC implements the switch timing, it seems like a dead end as far as giving it brain cycles.

Update: timing implemented in Serial Monitor, but the work day has begun so it’ll be tomorrow sometime that I finish. I will make this code available to others, either via pull request to MIDIcontroller library or a fork…

switch on, timer zero
short press
switch on, timer zero
bold press
switch on, timer zero
bold press
switch on, timer zero
long press

Question: regarding long presses, does the standard UI react right at 2s or does it wait till the switch is released?

Bold and Long press times are configurable in webconf. If you press and release before bold time then a short press event is triggered. If you press and hold beyond the bold time but release before the long time then a bold press event is triggered. If you press and hold beyond the long time then a long press event is triggered at the long time, i.e. before you release the button.

[Edit] An alternative was to have resolved this would have been to add CUIA actions for switch_press and switch_release within Zynthian!

1 Like

CUIA for switch_press and switch_release on each button would definitely make the task easier on my end - did I miss those in the list? Or are you saying that would be a good feature request? Cause it would, that’s actually what I expected to find when I finished building the controller and started figuring out how to make it talk to the zynth. The only ones I noticed were of the press categories.

I apologize if I was grumpy yesterday. It’s not like it was hard to handle this minor limitation, I was just disappointed cause I thought I was gonna get to play with my toy. You triggered my inner four year old and he’s a real jerk.

I am intending to get on top of C coding as a primary personal goal at the moment (I need more money lol) so once I’ve sorted the immediate problem and my device works (and anyone else who wants to do it my way), I would be very interested in participating in any solutions Zynthian might implement internally to make this easier. I would probably need a lot of guidance though, I’m new at C and also hampered by a lot of Pythonic instincts. I finish my logic and spend a lot of time cleaning up my code on microcontrollers.

If the _press _release thing isn’t a go, it would also be useful if one could query the delay times for switch presses over midi with a sysex - I daresay I could make the controller autoconfigure itself, if it’s possible to procedurally get the timing into the Teensy somehow. Maybe this is where OSC could come in? I assume there’s an OSC library for Teensy, haven’t looked into it, but I would guess that arbitrary messages are part of the protocol.

1 Like

What happens when we get to 127 CUIA functions?

You currently have twelve CUIA actions for the switches - if you instead implement a press and release for each, you can remove the other twelve, and gain four back.

Can someone point me to the specific code that handles the timing?

Do you mean this sort of stuff…?

No, that’s the actions triggered by a (fast|bold|long) press.

I would like to read the code that determines which sort of press just happened and calls the actions you just pasted. I want to get a sense of the path from there to the UI.

1 Like