Hi there, I am trying to build a rig using two keyboards and a behringer FCB1010.
I would like to be able to map the FCB pedals to select patches independently on each keyboard (E.G. Pedal 1 - piano sound on Lower keyboard, Pedal 2 - Rhodes sound on lower keyboard, Pedal 3 - lead synth on top keyboard without effecting the patch on the lower keyboard)
I am struggling to do this using ZS3s as it is impossible to recall a sound on the top keyboard without effecting the sound on the bottom keyboard etc…
I know I could simply create ZS3s for every permutation of sounds however this quickly requires a lot of ZS3s (more than I have pedals on the FCB)
I would also like to avoid directly controlling the mute buttons on the mixer if possible as the chains are still active, even when muted, leading to issues when unmuting them and also meaning that zynthian is using more processing power than necessary.
I’m completely stuck on this, any help will be gratefully accepted
As you already have noted, ZS3s store the full state for all chains. This way maximize the restore options because all info is saved. But you don’t have to restore all this info, right?
For instance, you can use the ZS3 restore options to restrict the chains that would be restored when recalling the ZS3.
Bold-push on any ZS3 to access the ZS3 options, then “restore options”, etc.
It’s not planned. ZS3 (should) cover all cases and we don’t want to have different types of “substates”. They would only add more complexity.
If you want a ZS3 affects only one chain when restoring, use the ZS3 restore options. They are super easy to manage and allow you to decide what chains/processors will be restored when the ZS3 is recalled. Also allow you to include/exclude MIDI learn from restore (excluded by default). In the future, we want to add options for other state subsets, like ctrldev driver state.
I think the discussion is not about the mechanism itself, that is powerful enough to fit almost every use-case, but about “default” settings. Current ZS3 restore options defaults are:
Restore All chains & processors => This could be restricted to “active chain” by default
Don’t restore MIDI learn => This has been added recently
Restore ctrldev driver state => This probably should be excluded by default
Indeed, we could have a “default restore options” view. This probably would make happy to every user Some thing like this:
( ) Restore All Chains & Processors
( X ) Restore Active Chain Only
[ X ] Restore MIDI learn
[ ] Restore driver state
ZS3 will ALWAYS save the full state. The options are for the restore phase.
We save everything, restore selectively. Saving partial states doesn’t give any advantage and complicate things.
But if you only save a selected chain, then on loading that Sub snapshot you’d overwrite the entire machine state yet again anyway. So you’d have gained nothing beyond a selective save itself.
This would fix the one half of this question that is not really missing, ignoring the one that is
There has to be a “selected chain only” option on loading too, in order for this to make sense.
…thinking it through though, at the Sub snapshot level this gets bloated fast: once a ZS3 contains several chains, you’d need a whole matrix to decide which chain inside it maps to which chain in the current project, which to keep, which to overwrite, which to insert and where in the chain order. I see…
…that brings me back to the implementation of a chain level of saving, somewhere between a Snapshot of the entire machine state and a sub snapshot (of the entire machine again).
It’s the Entire Machine-part that can feel a bit off for musicians.
Maybe that’s the real answer after all: something that saves and loads the state of ONE chain, where loading lets you either insert it at a chosen position, or overwrite a selected chain.
Imagine a per-chain snapshot enabling a curated library of favourite chains you’ve built over time, recallable whenever you need one, with their MIDI mappings or without, selectively. This could be really powerful
…But it would mean implementing a new kind of Save File Type… true…
Imagine ZS3 per Chain would – in a live scenario - enable you to tweak and fubar your sound and then snap back to the original state. (reloading the ZS3 for that chain only)
Pretty powerful technique in live electronics…
Maybe I’m wrong but I think you misunderstood the restore options. As I understand it you can save the state of everything and then choose to load only the chain that was active when saving. It’s equivalent to saving one chain and restoring only one chain, so a different mechanism wouldn’t be needed for that.
Trying to load the active chain from a snapshot - as you found out by yourself - doesn’t make much sense since there is no guarantee of the chain being in that snapshot, the chain being at the same place in that snapshot (left to right), the chain being the only chain with that instrument selected etc etc. There’s a whole pit of bees nests going down that way and trying to figure out what “the right thing to do” would be in each case. With limited dev power I’d rather they focus on something more meaningful (which they do).
Saving only a single chain (your new file type) could be useful in some cases but the question is how many users would need that regularly and how many such cases wouldn’t be resolved by the mechanism we already have.
i would use this daily!
…no, but seriously. Can someone explain the way we already have? because the only thing I ever managed to do with ZS3 loading was either adding it to the existing chains, or overwriting the entire machine state. I might indeed misunderstand this whole thing
…is pretty much exactly, what this topic is about… just saying.
I’ve tried. My zynthian doesn’t have a Load-Merge option.
Is this yet another Oram vs Vangelis thing?
Because as long as Vangelis cant handle midi clock, I can unfortunately not update and am damned to be stuck back in the stone age : ((((
The answer for this is: Use the ZS3 restore options.
Loading/saving snapshots is not related at all. We are talking of ZS3s.
If you think it’s related, then you are not understanding the difference between snapshots and ZS3s, and probably you are not using them adequately. I think the user guide explains this quite nicely…
Of course it has. Both Oram and Vangelis have it. @nemoy, you asked the same 1 month ago and you got the same answer. Come on!!
Save a zs3 not for each permutation, but for each (set of) chain settings you want to recall with a single pedal.
Make sure to uncheck each chain of which you do not want to recall any settings in the restore options. It’s subs can be left checked (note: the UI could be better here, e.g. by greying out subs of unchecked chains).
[ ] Chain x
[x] Processor a
[x] Mixer channel
Use Program Change to load (partial) zs3. The FCB1010 has 10 pedals, but 100 presets, at least in the original and with a UNO chip. Each preset can send up to 5 Program Change messages, so you can even mix and match. If there is a zs3 whose active chain to want to get active (for MIDI devices you have in Active mode, e.g. because they cannot switch channel), set that as the last Program Change. How do I know? Picked up a used one last Friday, I think I finally wrapped my head around it by now.
BTW @jofemodo, I would really dig as options Restore MIDI learn and Restore driver state (I think you knew the last one already).
So if I understand correctly, a workaround is to make sure you remove all chains you don’t want to save before saving - if you care about unneeded extra save state.
It’s not a workaround because there is no issue. It simply works like this.
ZS3s include the full state of All Chains & Processors + MIDI learn + Driver state.
You can edit the restore option to decide what you want to restore when recalled. The restore options can be improved, specially regarding the default settings.
Some thing like this: