So I’ve read the documentation quite exhaustively and attempted everything that was mentioned that I could find before posting…
For reference sake, let me post what the documentation appears to have to say on the subject outright:
2.3 Signal workflow
As introduced above, Zynthian’s signal workflow is based around chains of audio & MIDI processors that feed an audio summing mixer and MIDI outputs. This diagram gives an overview of signal paths which may help in understanding the flow of audio and MIDI signals.
2.4 Snapshots
A snapshot is the captured state of zynthian at the time of saving the snapshot. Snapshots are saved in a JSON file with .zss extension and can be loaded at any time, which effectively restores the state of the zynthian device when the snapshot was saved. Snapshots include:
- chains layout: configuration of each chain including its processors and how they are arranged and connected
- audio levels: (optional) physical audio interface settings
- sequencer: patterns & sequences
- MIDI settings: global MIDI settings, USB MIDI port names, etc.!!
- multitrack record settings: mixer strips armed for multitrack recording
- UI state: some user interface configuration relevant to the snapshot (most UI is configured globally)
- sub-snapshots (ZS3s): most other configuration (see ZS3)
Each time you overwrite an existing snapshot file, a backup copy is created. Backups can also be restored at any time, which can avoid much suffering. When you feel the panic, remember that zynthian stores the full save history for all snapshots!
Note:
Many zynthian users like to see snapshots as “zynthian project” files and it’s not a a bad approach.
2.4.1 Last state snapshot
When zynthian starts, it always try to restore the last state saved as this snapshot. It always trys to save the current state before performing some operations, like:
- power-off
- restart
- update
- clean all
- etc.
For convenience, the last state snapshot can also be saved or restored manually.
2.5 Sub-snapshots: ZS3
ZS3 means Zynthian Sub-SnapShot. A ZS3 is a partial state that is stored in memory and can be recalled very fast. ZS3s can be easily associated (learned) to MIDI Programs (program change events). Of course, all ZS3s are saved and restored with snapshots, including the default state of the snapshot when first loaded (ZS3-0).
Please bear in mind that in the case of USB connected MIDI devices there are two settings configured in admin under “MIDI-USB mapped by port” that affect this functionality. With mapped to port set the learnt settings will apply only to the specific USB Configuration in place at the time of learning. So if you add a USB hub to the rig the ZS3 sub-snapshots won’t act. Turning this off will allow control simply by the MIDI message only
ZS3s include:
- chains configuration: for each chain, MIDI channel, note-range, transpose, etc.
- processors state: for each processor, bank, preset & parameter values
- mixer settings: for each mixer strip, fader, balance, mute, solo, etc.
- MIDI devices configuration: active / multitimbral mode, etc.
- MIDI & Audio routing: connections between chains
- MIDI learning: MIDI bindings to processor and mixer parameters
- global settings: some global settings that can be changed by ZS3, e.g. MIDI transpose (most global settings are not available to ZS3)
- active chain: chain that was active when the ZS3 was saved
The key concept to understand how ZS3s work is noting that chains layout is not stored in ZS3s. In other words, chain’s layout is not modified when retoring ZS3s. You can’t add/remove chains or processors by restoring ZS3s because this is a slow operation and ZS3s need to be restored very fast.
When loading a snapshot that contains ZS3s, all the chains and processors are created. Later, when recalling the ZS3s, chain’s layout will remain the same. Although ZS3s can modify routing, splits, banks, presets, etc., the quantity of chains and processors will be unchanged.
Note:
For instance, if you are keyboardist that plays with several bands, you could have a snapshot for each band with ZS3s for each song.
Now based on this information, I naturally went and tried both options… I tried the snapshot, and the z53, both of them killed my delays that were playing, both of them reset sooperlooper
Then I went and checked if its possible to change a preset while these things run, that appeared to work just fine.
Then I went back to the documentation as a last resort, and checked to see if there’s any documented way to trigger a preset change via osc, but I didn’t find any.
I didn’t find any description of a way to preserve or lock any of the chains during the change, and I didn’t find a way to change a preset using a button.
Which lead me here… am I missing something in the documentation that you’re referring to?
Example flow: record a piano into a loop, change piano for an organ with a preset, loop stops.
Now I’d be happy to restrict the work flow to loading a bunch of instruments and muting and unmuting them just to get the ball rolling, and that’s exactly what I’m setting up even though its a pain, I’m just asking if it is possible since that would be a much more elegant way to do it.
