Close, but no Banana…

I’m having a lot of fun with my Zynthian, the quality and depth of the sounds are amazing, but as an instrument I can use live, I’m afraid I can’t see a way to use it, as the user interface isn’t conducive in the slightest for live performance.

I noticed a long push of the Layers knob brings up a lovely matrix of buttons labelled “Bank1” but these aren’t where you can save sound patches, these are sequences…:tired_face:

I just want to save sounds and view/access them instantly/easily. I’ve read and re-read the manual but I can’t see anything that shows or tells how to do this.

Can this be done? Is this possible? I so wish that that “Bank1” screen I see was for patches! Maybe the Zynthian isn’t for me?



Do you mean you want to store and restore patches / presets for instruments? The current way to store and name patches is rather awkward. (I hope this will change soon.) You can store a layer’s configuration using sub-snapshots. This requires an external MIDI controller to send program change messages. You can also save full snaphots with instrument configuration and recall from UI but this can take a few seconds because it clears and reloads all instruments.

If you want to select from existing presets within banks then you can do that, e.g. load Fluidsynth to a layer then browse the banks and presets.

I find quite interesting your proposal @VK5LA ! Having a grid for subsnapshots is quite easy to implement. In fact we could extend the zynpad, so pads can be bound to different types of trigger-actions, not only “launching a sequence”. When learning “subsnapshots”, the zynpad could be shown so you could learn a “free pad”. We could reserve a full page (4x4) of pads preconfigured as “program change” (subsnapshots). When subsnapshot MIDI-learn is started, this zynpad page can be shown. All the bits are there, we only need to add some glue:

  • implement the “program change” trigger-action on zynpad
  • preconfigure the 4x4 page of “program change” pads. Perhaps we could add an option for preconfiguring all pads on the current page as “program change”.
  • integrate zynpad on subsnapshots MIDI-learn workflow

@riban, is this the kind of kick&nice feature that you can implement in a session? Having a proof of concept of this doesn’t look too costly in time. I would do the third task :wink:


Am I understanding you @jofemodo … you would be able to create a snapshot, then program up to, say, 16 sub-snapshots, the triggers for which (program change) you could arrange in an 4x4 pad on the screen. Is that it?


Hi all and thanks for considering, to be clear, I’m looking for a screen the same as “Bank1”
Where I can store sounds like say a Piano, string pad, stab brass, bass guitar, drum kit, etc etc as separate sounds with its own button in that “Bank1”
Storing that sound should be as easy as creating it and having a button or a menu within the UI that gives the option to save it to a location in the “Bank1” area. Maybe a long press on the now saved sound within “Bank1” would give the option to rename it?
Once back at the “Bank1” screen changing sounds should ideally be instantaneous, so it would be useful to change to different sounds mid song, I.e Piano intro/verse then switch to layered strings for chorus then back to Piano…
Thanks you so much for considering my idea

Andy Williss
VK-QRP #752 GQRP #17085
Winkie, South Australia

Hi Andy.

It takes a while to understand what Zynthian can do. Like you, I’m looking for “instantaneous change” of sounds for live performance. What Zynthian currently offers is this:

  1. You create a sound layer using whatever synth engine you prefer (I use FluidSynth), and you apply midi and audio effects in a chain. When you’re happy, you save it as a “Snapshot”. A snapshot may have multiple layers.
  2. To load the snapshot, you select it from the snapshot menu. The difficulty here is that the snapshot is loaded from scratch, which takes time. You can’t load a snapshot via a “program change” command - you have to use the menu
  3. To get around the loading issue, a “Sub-snapshot” is available. Prior to your performance, you create a sound as in 1. and when you are happy with it, you save a sub-snapshot which can be triggered by a “program change” command. Then, using the same sound you modify it (different instrument/effect for example), then save that as a new sub-snapshot with a different “program change” command. When you save the snapshot, the sub-snaps are saved too. The idea is that you create as many different instrument sub-snaps (within that snapshot) as you will need for a performance. Then, all you have to do for a performance is load one snapshot, and use your stompbox (or or the buttons on the front of the Zynth or whatever) to get the sub-snap you want. It’s very quick.

Hope this helps.


So what we are talking about here is a program change selector screen:

  • A grid of buttons which each sends a program change
  • The grid size may changed
  • Different banks of buttons may be selected

Then we use the existing sub-snapshot mechanism which is triggered by the MIDI program change messages. Some questions:

  • Does each button only send program change on one MIDI channel to control just one synth engine?
  • Can we stack program changes on each button, i.e. send (different?) program change commands to several synth engines simultaneously?
  • How do we access this screen? (Maybe initially from the main menu)
  • Should the size of the grid (quantity of buttons) be adjustable?
  • Should the buttons be different colours, e.g. to indicate MIDI channel?
  • Should labels be editable? Where would that be stored?
  • Should there be banks of buttons or do we just say there are a constant quantity of program change buttons available and user should use full snapshots to expand?
  • Should bank selection be done with an encoder or with another set of buttons? (My VZ-1 has 8 program select buttons and 8 bank buttons to give 64 program change options.)

A simple grid of buttons labelled numerically to trigger program change seems like a nice feature, similar to many synth’s program select buttons. I would suggest keeping it simple (initially) - just that grid of program change buttons. The allocation of presets to program change would continue to be done via sub-snapshot mechanism. The program change would be sent to the relevant layer based on MIDI channel. Maybe initial implementation has an encoder that moves between channels so each page controls a different layer.

Of course - before all this - we need to be able to configure sub-snapshots which seems to have been a casualty of recent changes. Docs say to press snapshot button twice but that doesn’t work!

Hi riban,
This is probably exactly what I would be looking for.
I’m confused about what the snapshots and midi program changes you are referring to however.
I don’t fully understand (yet) how all this works. Plain English simple to store sounds :+1:

The grid of buttons, grid size and different banks of buttons Yes!

Each stored sound should be capable of using different engines, ie DEXED marimba sound layered with a piano from another engine should be possible and easy. Split keyboard as well, I.e bass guitar sound left hand strings right hand, editable split point

Button colour might be assignable with midi channel? Your main piano sound in “bank 1” might be green, to correspond with Midi#1 assigned to your main controller, and drum sounds button blue for midi#2 assigned to drum pads on a smaller controller?

Labels and bank names editable

Maybe in “live performance” mode the 4 buttons along the bottom could select Banks and each bank screen could have up to 16 buttons? Configurable in menus?


Andy Williss
VK-QRP #752 GQRP #17085
Winkie, South Australia

The concept of sub snapshots (zs3) is that the current configuration of a layer is assigned to a MIDI program change and may be recalled quickly with that program change. Due to recent changes (which are still in flight) the docs didn’t describe this accurately. (I just tweaked them.) To add a ZS3:

  • Within admin menu, enable “Program Change ZS3”
  • Create a layer and configure as desired
  • Within layer control screen, bold press the snapshot/learn button - this enters control MIDI learn mode
  • Short press the snaphot/learn button - this enters the ZS3 learn mode
  • Send a MIDI program change from an external MIDI controller
  • Repeat for other layer configurations

When a MIDI program change is received, the corresponding layer changes to the associated configuration. You can manipulate existing ZS3 by highlighting them in the ZS3 learn screen and bold press SELECT.

Of course this all requires an external MIDI controller capable of sending MIDI program change which is the constraint that the (hopefully soon to be added by @VK5LA) feature request would address.

If you have a v4, the 4 buttons down the screen are pre-configured as Program Change 1-4.

Ohhh! I was talking about allowing the zynpad to trigger different kind of events, not only “sequeces”. Zynpad already implements all the bits we need:

  • the grid GUI
  • several pages
  • customizable pads, including name and group

We only need to implement other types of trigger and “program change” could be a profitable example.

If we integrate this with the ZS3 subsystem, it would solve the use-case and bring us an improved workflow for zs3.


It is planned to allow other types of event in sequences and program change could be included but that isn’t really that intuitive. I know that is not what you suggest but it fits the current implementation. I would be worried that the UI becomes confusing of the pads were random triggers. (I know, not random!) I guess it would be like a virtual launchpad where pads had configurable actions. Let me ponder…

Exactly!! Like a hardware launchpad

Okay - that will take some time to consider and (possibly) implement. I think we should wait until the API is available which may make such changes simpler. The UI needs to be refactored for the API anyway.

In the meantime, I have added the ability to add program change command to the start (first step) of each pattern. You will find the option in the pattern editor menu in testing. (The library actually supports adding program change at any step but user workflow doesn’t demand this and the UI is simplified by constraining to first step only.) This does work but has side effects which makes it suboptimal (or quite useless - you choose!).

When a subsnapshot is selected the control screen for that engine is displayed which moves away from zynpad. This is not good behaviour. @jofemodo should we stop this behaviour, i.e. not change view when subsnapshot change occurs? I think it is disruptive with limited (if any) benefit.

I advise configuring the pattern to have one beat with one step per beat and configure the sequence to be one-shot. This will mean triggering the sequence by hitting zynpad will send the program change and then immediately stop. The sequence doesn’t start until the next bar so there is a delay between hitting the pad and the program change being sent if other sequences or MIDI player are playing. (I have considered adding an instant start mode for pads but need to consider how it would work - there are some interesting considerations.)

1 Like

I have created a development branch called zs3_learn which has the following changes:

  • Does not change view when a program change is received
  • Updates labels in mixer / control screen when program change received
  • Shows all 128 programs in learn screen with “(empty)” appended for unconfigured programs

The last point allows manual configuration of any program change and hence does not depend on external MIDI controller to assign program change to ZS3. I have played with this today a bit and find ZS3 far more accessible and usable. I may even start to use it… :wink:.

With these changes it would be possible to configure zynpad to select ZS3 all within zynthian UI without external MIDI controllers.

@jofemodo I like this workflow but did not apply directly to testing so that you could peer review. I have submitted a pull request.

1 Like

Nice to see that the “SubSnapShot” concept is penetrating your northern-man soul :rofl:
I like all changes you propose, but let me play with them a little bit and let’s push them to testing ASAP so everybody can enjoy.

Anyway, i would like to clarify that ZS3 is already very useful for instrument players wanting to change sounds as fast as possible.

  • Requirements: You need some Program Change buttons and some space in your memory for remembering what you “learned” on each one.
  • Limitations: Current implementation was not thought for managing tens of zs3.

In fact, it was modeled with my personal use-case on mind:

  • Grand Piano
  • Rhodes/Wurly EP => 2/3 presets
  • Clavinet => 1/2 presets
  • Hammond => 1/2 presets

I can remember 8 presets on 8 buttons and for me, most of times, this is more than enough. Obviously, “most of times” is not “always”, and we always want to improve, so we reach the current sweet point, thanks to @VK5LA and @riban.

The new improvements implemented by @riban will make ZS3 more useful for those not having Program Change buttons, or those (like me!!) with little to not memory at all or wanting a more explicit/visual selection interface that allow managing tens of zs3s.