Hey. I’m new here, and I’ve had the V5 for a few weeks and am tinkering around with it. One of the reasons I got it is because I’m a programmer and I figured if there was anything it couldn’t do I could modify it. I’m checking in because I’ve found something that I want it to do and can’t quite figure out how to do it from the standard UI, and am thinking about writing some plugins. But I want to check because it’s possible (likely?) that I’m missing some other built in way to do things.
What I’m looking for is essentially a way to quickly select from a bank of one to two dozen tones. Most of these tones are presets already in one of the packaged engines. This can be accomplished with ZS3s and program changes. But I also want the ability to pick two tones and have it split the keyboard into two regions, or layer two different sounds on top of each other. This can also be accomplished with MIDI routing and ZS3s and program changes. But I can’t really figure out if there’s a good way of doing both of them together. I have a 64-button MIDI control pad I want to be able to use to switch between the tones I use often (say 16 of them). I don’t mind dedicating 16 of the buttons to call up the presets, but I don’t really want to have a separate ZS3 for each possible combination of layers or splits. I’m envisioning some custom plugin that has a dial for “instrument 1” that has about 16 options, a second dial for “instrument 2” with the same 16 options, and then a dial that has “inst 1 only / split / layer” as an option. Or something like that.
Which version of zynthian are you using. Oram or Vangelis? Vangelis is main focus as we head towards a new stable release, but IIRC these options are available in both:
Split - Use the key transpose and range feature to define which key range each chain responds to.
Layer - Assign the same MIDI channel to multiple chains for them to respond to the same MIDI input.
Select multitimbral mode for the MIDI input so that it is received by the relevant chains.
In Vangelis there are some enhancements to support similar workflow with active mode too.
I found the option that each instrument chain has for MIDI note range and transpose. I also found the “MIDI Keysplit” engine, which is not enabled by default but can be easily enabled in the webconf tool. Both of those can be used to do splits.
I don’t think I did a great job of explaining my problem, Let me try again. Let’s say for example’s sake I have three different sounds, coming from three different instrument chains: a piano, an organ, and strings. I can set up a ZS3 (SubSnapshot) corresponding to each of these chains, and a program change signal associated with it. Then, that means the P1,P2, and P3 buttons on the zynthian are now effectively piano, organ, and strings buttons.
But lets say I want to have a button for piano in the upper register and strings in the lower. And another button for organs on top and piano on bottom, and another for … we’re already at nine possibilities, and the idea of having a button for each combination kind of falls apart. It would be nice if I had one system for switching instruments, and a different independent system for switching MIDI routing / splitting. My understanding is that ZS3 restores the entire state of the chains, so I don’t think I can use subsnapshots to accomplish both at the same time (Maybe I’m mistaken about that)
You mention that there’s similar support in active (not multitimbral) mode in Vangelis. Can you point to that and elaborate? It might solve what I’m looking for in a way that has nothing to do with ZS3s.
What about transposing? Most of times i split my keyboard and map instruments to lower and upper, i need to do some octave transposing, what increases the available combinations.
Would you add a “Octave” wheel too or forget about transposing?
Please, could you elaborate a little bit more the use case your proposal fits in? I mean, how is this tool used in stage and rehearsal.
In the ZS3 view, bold SELECT to access the ZS3 options from where you can choose which elements of each ZS3 are restored. By deselecting the chain option, transpose and split are not restored (as well as some other parameters). Similarly, deselecting the processor (instrumement) you can avoid restoring its preset and parameters.
I don’t really understand what you are trying to do though. Do you want to dynamically change the transpose and split points? If so, change them before saving your ZS3 so that they are stored and my be (optionally) restored. Do you want to use ZS3 to switch preset/patch of each instruement? Your workflow is unclear to me. Maybe a concrete example of what you want to press and what you want to change (and not change) and the reason for this would help us.
There is an admin option “Active MIDI Channel”. With this disabled, a MIDI input set to Active Mode will be received by all chains with the same MIDI channel as the currently selected chain. With this disabled (default) only the selected chain receives the MIDI input.
Tell us exactly what you want to do. It may already be possible out-of-the-box.
I have re-read the original post and I think I understand the requirement…
A set of Program Change that will select processor (instrument) presets/patches.
A set of Program Change that will change the note range & transpose.
This can be done with ZS3 mapped to Program Change:
Create your snapshot with all required chains.
Configure each note rnage & transpose and save as ZS3s.
Configure these ZS3 to not recall processor parameters.
Configure each processor preset and parameter overrides. Save to ZS3s.
Configure each of these ZS3s to recall just the desirec processors.
Now you can use some PCs to recall the split layout and other PCs to recall the instrument presets.
Be aware that there may be other chain parameters that you tweak as you enhance your snapshot which may want to be shared across ZS3. If you find this, recall each ZS3, make the change then use the ZS3 options to overwrite the existing one.
Remember that everything is saved for every ZS3 so the ZS3 contains the snapshot at that point but you can choose what is restored when that ZS3 is recalled.
Hi @riban. I’ve looked into the partial ZS3 restore, and I think I can make that work. Thanks! Didn’t know that was an option
It might take me some time tinkering with it to get what I’m after. I’ll post something about it when I do. I’m pretty sure if I understand things correctly it’s just a matter of time and configuration at this point.
@jofemodo yes, transposing (and sound level balancing and a few other things) are also on my plans but I was focusing on the thing that was blocking me.
One more thing worth planning for before you build out a big bank of ZS3 states, since it bites most people the first time they gig with splits: think about what happens to notes that are already sounding when you switch. If a state change alters the key range or the channel routing of a chain while a key is held, the note-off can end up routed somewhere that never got the note-on, and you get a stuck note. Sending an all-notes-off (CC 123) to the affected chains as part of the switch, or simply only switching between phrases, saves a lot of confusion later.
The related one is controller state. Sustain pedal down across a switch, or a mod wheel that was up, doesn’t necessarily get re-sent to the newly active chain, so a patch can come up sounding wrong for reasons that look like a preset problem but are really a CC-state problem. If you do go the custom route, re-sending the handful of CCs you care about after a state restore is a small amount of code and makes the whole thing feel much more solid.
On splits specifically: if you want a crossover rather than a hard boundary, two chains with overlapping key ranges and opposite velocity curves in the overlap region gets you most of the way there without any code.
Since you mentioned plugins - before writing one, it’s worth checking whether what you want can be done by an intermediate MIDI filter chain instead. Filtering, transposing and re-channelling MIDI in front of the existing engines is usually far less work than modifying the UI, and survives upgrades better.
Hey @HelenMarsh , my approach for this is to put a MIDI filter plugin at the beginning of every chain I use.
Instead of disabling the MIDI routing to a chain completely, I only filter out Note On events when that chain is supposed to be inactive. All other MIDI events are still allowed through, including Note Off, Sustain Off, etc.
The idea is that an inactive chain cannot start any new notes, but it can still receive the events needed to properly terminate notes or controller states that were already active before switching the ZS3. So, for example, if a note is still sounding when I switch states, its subsequent Note Off can still reach the original chain even though that chain is now “inactive”.
I’m not entirely sure whether this covers exactly the edge case you are describing, but so far it has worked very well for me. It also became much more reliable after the bugfix recently made in Vangelis (see the other forum post).
