@mheidt that kind of interface may prove uncomfortable, like playing an original game of Pong, i.e. having to position the rotary knob in an up, down or neutral position to trigger movement. It would require Zynthian to send continuous, periodic up / down messages to itself whenever the CC was outside a deadband, e.g. 0…55 = down, 75…127 = up. Also, would you expect more rapid movement if the control was further away from centre (64)?
and the knobs don’t have a click. forget about it…
It all works as a mental image until . . . .
I suspect we’ve all been there. . . 
I tried to tell you in my first comment:
2 Likes
but what we could do is defining 6 CC Actions for UP/DOWN, the 3 kind of clicks and BACK?
In that case I could use the pads to navigate through the menu.
From a post a long time ago . . . .
Be good for testing as well… as long as we could get some MIDI status out to tell us which page and selected item(s) the page is displaying, possibly in a test mode …
as long as it’s configurable. I want to have back and select started from f and c. 
Hi @zynthianers!
I’ve mapped Master Channel note-on events to CUIA (Callable UI Actions). That allows to fully control the UI using only MIDI events:
Currently the map is hardcoded like that:
note2cuia = {
"0": "POWER_OFF",
"1": "REBOOT",
"2": "RESTART_UI",
"3": "RELOAD_MIDI_CONFIG",
"10": "ALL_NOTES_OFF",
"11": "ALL_SOUNDS_OFF",
"12": "ALL_OFF",
"51": "SELECT",
"52": "SELECT_DOWN",
"53": "SELECT_UP",
"64": "SWITCH_BACK_SHORT",
"63": "SWITCH_BACK_BOLD",
"62": "SWITCH_BACK_LONG",
"65": "SWITCH_SELECT_SHORT",
"66": "SWITCH_SELECT_BOLD",
"67": "SWITCH_SELECT_LONG",
"60": "SWITCH_LAYER_SHORT",
"61": "SWITCH_LAYER_BOLD",
"59": "SWITCH_LAYER_LONG",
"71": "SWITCH_SNAPSHOT_SHORT",
"72": "SWITCH_SNAPSHOT_BOLD",
"73": "SWITCH_SNAPSHOT_LONG"
}
Although filter rules can be used for re-mapping, it should be directly configurable for better UX.
Enjoy!
5 Likes
Could we add?
Audio start Recording
Audio Stop
MIDI Start Recording
MIDI Stop
Play Audio
Play Midi
These could then appear in the UI Actions in the Encoders …
It means that you can use the zynth as a VERY basic looper from the i/O pins. . .
and also allows collection of evidence material for tests. 
Play commands should have a parameter (the file to play). I suppose we want “stadard” MIDI messages, so it should be a “file index”. If no parameter is passed, it could play the last one.
Anyway if you want a looper, i think the SooperLooper plugin, although a little bit outdated, will perform a lot better and can be easily mapped to MIDI using the MIDI-learning stuff.
Regards,
Now how big so we make the file index …? It could be a lot of files to choose between isn’t this how MIDI ended up with Progam Select MSB LSB hell . . ?.
Perhaps just one currently selected file in context is the way forward rather than the complexities of populating a list with legitimate file indexes?
I’ll play around a bit . . . .
For those who wonder:
51=SELECT jumps to the end of a list
And SELECT_DOWN and UP are reverse to what humans are thinking.
So Down is actually selecting the item above the selected…maybe because the index is getting a value that is one down to the previous one
And @jofemodo, the Channel 15 (16) is not shown in the midi log. Only when I select the Midi In of my V25.
The app that @Baggypants linked to is quite buggy. Labels not matching the input boxes f.e.
Furthermore it is using zero based channels like they are transfered over the wire. But imho that is a problem on their side. Or should we switch to 0 based in webconf as well?
I think we should keep human facing elements as 1 based, i.e. MIDI channels 1…16. The geeks amongst us (you know who you are) are capable of the complex math involved in adding / subtracting one!!! 
yes, agree. I filed a bug report in their github.
Well of course it’s buggy, did you not see what it was forked from?
I took the one you forked from.
1 Like
This key is just off the top of an akai mpk MINI KEYBOARD …
|| MIDI || COMMAND || NOTE ||
|“51”| “SELECT”, | Eb|
“52”: “SELECT_DOWN”, E
“53”: “SELECT_UP”, F
"64": "SWITCH_BACK_SHORT", E
"63": "SWITCH_BACK_BOLD", Eb
"62": "SWITCH_BACK_LONG", D
"65": "SWITCH_SELECT_SHORT", F
"66": "SWITCH_SELECT_BOLD", F#
"67": "SWITCH_SELECT_LONG",G
"60": "SWITCH_LAYER_SHORT", C
"61": "SWITCH_LAYER_BOLD",C#
"59": "SWITCH_LAYER_LONG",B
"71": "SWITCH_SNAPSHOT_SHORT", B
"72": "SWITCH_SNAPSHOT_BOLD", C
"73": "SWITCH_SNAPSHOT_LONG" C#
The current default CUIA note-mapping has not been deeply thought, but you can re-map it quite easily with a few filter rules. Anyway, i will be very happy of improving the “default” mapping to something smarter. Proposals are very welcome 
In case you are remapping, please stay within 25 keys from c to c, the range of the small ones.
Personally I don’t care, because I use the keyboard to play music and program the tabs and buttons for something like that.