CUIA Action for Program Change?

Maybe there is a better way to do this, but I was thinking in a way to change ZS3 subsnapshots using a score page turner (something like this)

I was thinking that it could be two CUIA actions:

  • Last Program change +1
  • Last Program Change -1

Maybe there is a better solution, but I could not find it.

I think you should open a “feature request” in our tracking system:



I want to say that my Idea is to have a way to quiqly change between snapshots and/or ZS2 states minimizing risk of make a mess by pressing the wrong key or taking hands off the keyboard.

I know that here is not the right place to say this. But I want to complain about the current state of MIDI controllers. My piano teacher is an organist and he has an digital organ at his home. It’s incredible how old organs are so well thinked. For example, this buttons on the edge of the keybards, you can press them with the thumb to change presets. And, obviously, a lot of pedals for the same purpose.


It’s not a complaint about zynthian, it’s about the fact that very antique organs has solved problems in ways that seems that current MIDI controllers are clear regressions.

1 Like

You highlight conflicting requirements. The organ preset recall is based on a one-to-one relationship between button (stop / pedal) and preset. This was implemented mechanically on large old organs and electronically on modern (>1970’s) organs but mechanical switches are expensive so synths and MIDI controllers tend to have fewer buttons and use menus or increment/decrement buttons to recall presets (patches). This is suboptimal in many workflows and to make matters worse, they often fail to give user feedback, i.e. you don’t know what preset you have selected, just that it was one higher/lower than the previous. This also fails to give direct access. You have to step through presets to reach the desired one.

Our friend @freeKey was eager to solve this issue so I worked with him to design a button panel to recall presets. Unfortunately life for in the way and that panel is still in our heads but maybe it may make it to real life soon… The concept is trivial but designing and building something that meets a wide user base may require some consideration, e.g. how is selection indicated? How many presets? Are they banked?


Our friend @freeKey was eager to solve this issue so I worked with him to design a button panel to recall presets

That sounds really nice. I hope to see this panel soon (or take the time that you need) :grinning:

I think that organ consoles are designed in a very clever way in the perspective of an organ performer. But also I understand that the organ stops have only two states (on/off) a synth is far more complex, it could have faders, knobs, switches, patch cables, etc.

So if you think in a fix number of a preset, whatever it be, there will be allways someone who think that the list is too short. That’s the reason why I think that could be more useful a limitless list with a pagination system like up and down buttons. Plus, you can use the pedals of a socore page turner to navigate the list.

Also, I don’t know what is the optimal solution here, but I’m very happy with the new ZS3 subsnapshots in multitimbral mode. I think that any solution should be build upon that.

I know that I’m not able to help here. And I don’t want that you feel that I’m trying to impose solutions that are only useful in my workflow or in my use case. I’m, mostly, using zynthian to play with my band. And I suggest things based on my needs, but I think that this suggestions are useful to anyone that, like me, use zynthian as replacement of a keyboard workstation.

This is my use case and I solved it pretty easily using [this MIDI controller:

You can assign a different MIDI Program Change (PC) to every button (24) and you have two banks, that makes it 48 Control Change (CC) in a single controller.

And you have 8 encoders x 2 banks = 16 encoders for CCs :slight_smile:

Plus a volume slider that you can also assign to any CC.


But can it send program change?

If the buttons are assignable to program change that solves all my inmediate problems.

But I still thinking that CUIA action for Program Change Up and Down (Last Program Change +1;-1) is a good alternative.

This is my suggested workflow, thinking in a gig.

  • Step 1: Put all engines cloned to channel 01
  • Step 2: Then you use MIDI Event filter to block all MIDI signals to all engines.
  • Step 3: Use ZS3 States to unblock Midi Events to the engine you want to play.

Now you can set program changes to quickly load Engine and ZS3 State. Like:

  • Program Change 01: ZynAddSubFX - Preset 1
  • Program Change 02: SetBFree - Preset 1
  • Program Change 03: Dexed - Preset 1
  • Program Change 04: ZynAddSubFX - Preset 2

You can set the full song list with all config changes and you only need to press next The risk of mess things up is minimum. I think is a good Idea, I don’t know if someone else agrees with me.

I meant Program Change, I’ve fixed the post. You can program any MIDI code you want, PC and CC.

IMHO and my experience, musicians learn very quickly which button selects which preset, they are used to navigating menus in a rush, this is a bless for them.

1 Like

Hi @Andres !

I think you are overcomplicating things. You don’t need to clone all chains to channel 1 nor the MIDI event filter. You simply set Stage Mode (Omni On) from the admin menu.
Then, you load the engines you need and learn the ZS3s you want. When recalling ZS3s, active channel will change as learned and all MIDI events will be redirected to it. Quick and simple. Try it and tell me if it works for you and solve your use-case.

Anyway, having CUIAs for selecting ZS3s seems a good idea to me and it will be implemented in the near future.



I will try omni mode, to see if it works for me. But every use case is a world, I don’t know if someone else has the same needs.

I mostly use multitimbral mode because I’m more comfortable playing with two keyboards. But most of the time I try to avoid to carry two keyboards for a rehersal. So I have to adapt a setup for two keyboards to one keyboard.

Omni mode makes things very easy, as @riban said you add the engines you need and then you save the different presets per engine in ZS3 snapshots. All is easy to understand and configure.

OTOH multitimbral mode allows you to do more complicated things at the price of complexity. In this scenario every engine sits in a MIDI channel and you have to configure the controllers instead of the zynthian. This is probably good for studio work but IMHO too complex for stage play,

If in some themes you need two keyborads simultaneously, you could use some MIDI channels to split the keyboard and play each preset with each piano.

Is complex for stage play but it depends. I can set, for example a snapshot for a stage plays, all the complexity resides in configure the snapshot, but in the stage you only need to worry to make the correct Program Change.

I think that the last staging version is awesome. It solves all my problems.

There is room for make things easier. But I don’t want to be seen as a guy that demand things without give nothing.

I use two keyboards by personal choice. I try to avoid split the keyboard because in a improvisation, I don’t have to worry of the split point.

I have a lot of work now, but in the summer I think I should have free time to try other ways to setup my snapshots.

1 Like

For me the main difficulty with multi-timbral mode when you have more than one MIDI controller is that you have to configure the proper MIDI channel in the controllers to use the proper engine.

For example let’s say you have 4 engine chains:
-CH 1: Pianoteq
-CH 2: Sfizz
-CH 3: ZynAddSubFX
-CH4: OBxd

You can have many presets for each engine, easy with zynthian.

But in multi-timbral mode you will need that your MIDI controller uses the proper MIDI channel. And for me this is a great problem as you need to also configure the controller, if you want to use different MIDI channels.

In omni mode the MIDI channel of the controller does not matter, that makes things very easy.

Of course IMVHO.

I have added /CUIA/PROGRAM_CHANGE [pgm, chan] in testing branch and added default computer keyboard mapping for keys 0…9 to send program change on the currently active channel in Omni (stage) mode. This means you can plug in a USB computer keyboard or numeric pad and trigger program changes 0…9 on the active chain (only in stage mode). Wireless numeric keypads like this can be obtained for £10 or less which is a very cost effective program change system.

Remember to press numeric lock to enable program change. Other keys could be mapped to other functions, e.g. the arrow keys (2, 4, 6, 8 with numeric lock off) could select chain and adjust fader level. (They don’t by default due to an oddity with the keymapping…) You may prefer a wired USB keypad which may be a few quid cheaper. There are suppliers that provide these for just a few $$$.

[Edit] We may wish to install numlockx and add a startup script to set the numlock state, e.g. DISPLAY=:0 numlockx on or DISPLAY=:0 numlockx off based on a value saved at shutdown.


This is nice! I have always had the idea of sending MIDI Program Change commands from a numeric keypad. It would be awesome that you could send any number, not just bound to keystrokes.

I’ve been looking for a MIDI controller where you could select the number and send it with just a click. I had even thought of making a simple program to do it, but when you are in stage it has to be very simple.

Thanks for your hard work!

That’s a huge problem. Now I solved that setting both keyboards fixed in a specifict channel. Lower keyboard keys and CC are in Channel 1, pads are in Channel 10. Upper Keyboard keys and CC are in Channel 2 and pads in Channel 11.

Then I clone all chains to channel 1, and with MIDI filter I can silence the chains that I don’t want to be emiting sound or make them recive only one specific channel.

To be honest, the band where I play is in hiatus now. We are making rehersal again, but we start rehersals in July, and almost half of rehersal session have failed. Part of be in an amateur rock band. But I have not tested my method in a real life gig.

1 Like

I considered this but have a few issues with it.

The first goal was to provide instant (one button press) selection of preset. Having to type a number then press Enter doubles the key presses and is more awkward than just pressing the button you want. Typing the number then waiting for a timeout isn’t ideal for those wanting instant change. 10 instant presets may suffice for many workflows.

We would want/need an indication of the numbers entered which might interfere with other workflows, be awkward to implement and not necessarily available, e.g. headless or remote Zynthian.

Maybe we could add a feature in the future and maybe offer a configuration to choose behaviour. I did consider expanding the quantity of presets by using modifiers, e.g. 10…19 if Shift is held but there are technical challenges to this which would have delayed the feature landing. The current implementation fits the current architecture so was added simply. Maybe we live with it for a while and see what ideas emerge. (A feature request in the issue tracker might push that along!)

I don’t think this is right. In multi-timbral mode each control learns the MIDI CC and channel so you can use one or more controllers to control one or more parameters in one or more engines. This is pretty flexible. It may require a bit of time setting it up but if you have a fairly static rig then it is a one-time effort.