It’s growing on me…
It would be nice if when loading a snapshot I could load it as a new layer, as opposed to wiping out all other layers. Or am I missing something?
Gonzo
1 Like
A snapshot is a full configuration including the layers, their configurations, sequences, etc. We don’t have the concept of incremental snapshots or merging them which would present some challenges which i don’t see being sufficiently beneficial.
OK, so is there a way I can take my single-instrument FluidSynth snapshots (which I have spent some time tuning to my liking), and combine them into a single multi-layer snapshot?
You could submit a feature request to allow merging of snapshots, e.g. being able to select which layers are merged into the currently loaded snapshot. I took a quick look at the code and this could be done but some consideration would be needed to ensure it is desirable and does not break anything. (There is a slight complication with the way engines are instantiated that stopped me from just coding this!)
You could edit the snapshot file. It may not be much fun but if you dare, here is how you could do this manually:
- Within webconf, navigate to LIBRARY->Snapshots
- Select a snapshot you want to merge from the list on the left hand side
- Click the download button near the top right
- Open the downloaded file in a text editor - this is JSON format
- Within the “layers” section, copy the List entry for the layer you want to merge, i.e. everything between (and including) the { } curly brackets (probably starting with “engine_name” and ending with “active_screen_index”).
- Repeat to edit the snapshot you want to merge into and insert the copied text into the “layers” section, remembering to sperate it from the previous/next list entry with a comma
- If required, change the “midi_chan” value to avoid clash with other engines
- After saving your changes to the JSON (.zss) file, upload to Zynthian via webconf
Sorry that is a bit (lot) low-level and may require some technical experience to perform but it is a way to combine snapshots. Ugly but it works! (Sounds like me!!!) Good luck.
Thanks @riban . That worked. Almost. It took the plugins and their setting, but didn’t take the transposition. Do you have a file spec for the snapshot files? I’m happy to work my way through it, and pick up all the bits.
BTW, there seems to be multiple (3?) instances of midi_chan per layer. I changed all three.
I moved this to a new topic to avoid dragging zynmixer thread too far off topic.
There should be a single instance of midi_chan per engine. Within the “layers” section there is an entry per engine and each of these has one midi_chan setting. These should all be different to each other.
I am not aware of a specification for the snapshot file - I worked this out empirically. Here are some pointers:
- Snapshot files are standard JSON format with the file extension .zss
- There are (about) 11 top-level data items:
- index - not sure what this is
- layers - an array of layer configurations
- clone - an array of MIDI cloning configuration
- note_range - an array of note range and transpose settings
- audio_capture - an object describing audio input routing
- audio_routing - an object describing audio output routing
- midi_routing - an object describing MIDI routing
- extended_config - an object describing ???
- midi_profile_state - an object describing the MIDI profiles
- zynseq_riff_b64 - a data item containing raw sequencer content
- audio_recorder_out - an array outputs routed from the audio player (this looks like it needs rationalising)
Be aware that this is my interpretation and may be erroneous or incomplete and may change without notice, so don’t spend ages writing some clever application or script to process it as that might not work tomorrow… 
.
I was thinking of using the mixer instead of sub-snapshots. But again, the info that is shown on the mixer is not sufficient to identify the instrument when you have duplicates of instruments that are transposed or otherwise modified.
In the snapshot file, there can be more than one entry of midi_chan per layer. If you add in audioFX on a layer there will be one there, which, I assume should be the same as the main layer setting???
So, when I manually merged the snapshots, I copied the section in BOLD:
“layers”: [{“engine_name”: … “active_screen_index”: 0}], “clone”:
There seems to be only one “clone” in each snapshot, so that makes the position easy to find. As @riban said above, you put these sections (between curly brackets) separated by commas.
If you have transposed the instruments, then you will have to go through each layer after you load them onto Zynth and adjust the transposition. You can do it manually in the snapshot file, but it’s tricky to find the right one.
I loaded 10 snapshots of FluidSynth instruments, and it worked, but the encoder knobs were a bit jumpy, and there was a bit of hiss. I guess that might be from 10 instances of FluidSynth running at the same time…??
In the end, I think it is a better solution for quick-change instruments than subsnapshots IF
- you could merge the snapshots from the UI (it means you don’t have to prepare in advance the instruments that you are going to need to change quickly)
- the mixer showed the snapshot name
- there was a way of selecting a layer from a stomp box
Gonzo
@gonzoB you are right that each engine within a layer shares the same midi_chan value. I didn’t test with such a config.
Certainly submit a feature request for merging snapshots. I can see the benefit of that. Maybe offering the layers to merge / overwrite during the merge process would be advantageous, e.g.:
- From snapshot view, select snapshot to merge
- From contect menu select (new option to) merge snapshot
- List of layers is displayed
- From list of layers select layer to merge
- Show list of vailable MIDI channels
- Select MIDI channel to merge
There is not currently the concept of a loaded snapshot. Snapshots are a transient state. I believe it would be advantageous to record the currently loaded snapshot which would facilitate showing its name. I also think that changes applied to the snapshot might result in display of the name being modified, e.g. suffixed with an asterisk or shown in italics. These are common UI indications that an unsaved state has changed from its saved state.
Do you mean highlighting a channel from a stomp box? That would work well with in Stage Mode and is a kind of MIDI learn type feature but differs in fundemental concept from the current MIDI learn, Maybe something we can add. There is a way to use some USB foot pedals, e.g.
to act as up/down buttons (see work by @wyleu on this and webconf INTERFACE->UI Key Binding). I think this a rather expensive, ugly and restrictive approach but if it provides exactly what you want it can prove effective. You could do something similar MIDI or OSC - see user manual section on CUIA, e.g. enabling _Master Mode) and configuring MIDI foot pedal to send notes 52/53 on the master channel. This isn’t the same as direct selection of a channel by individual stomp pedals which would require a feature request to be implemented.
Not in your list but it would be advantageous to be able to rename layers so that this may be displayed in the channel strips of the mixer (rather than just the root engine and preset names).
There are a lot of topics being discussed here and I do urge you to submit feature requests for some or all of these - they (mostly) make a lot of sense. When a feature request is reviewed it is considered in the context of the whole system and often implemented in a novel way that may not be initially obvious to the requester due to some technical constraints or advantages that can be provided to other parts of the system. (We tend to see things from our workflow perspective and can sometimes miss how a feature may impact other workflows detrimentally or beneficially, depending on how they are implemented!)
Sorry to appear a meanie but it is more likely that features / issues will be impemented / resolved if they are reported as individual tickets. Combining several requests in a single ticket makes it difficult for developers to pick up and work on the part and to track progress, e.g. implementation of a full feature may take some time and effort but the ticket can’t be closed due to other elements requiring resolution and discussion within the ticket becomes confusing as topics cross over. It may seem petty but it would be advantageous to report these separately and is more likely to get faster support (although there are no promises ).
@ meanie, request adjusted accordingly.
1 Like
if you are editing JSON then a good text editor can help, e.g. Notepad++ with the JSON plugin.