Saving individual synth patches

This has been touched in a couple of places, like Saving presets and to some degree How do I save a sound so that it’s instantly available?, but I’m bringing it up again since it really seems to be something that is missing.

The workflow I’m thinking of is that I’m working on a project, saving the project as a snapshot as usual, but at some point I come up with a sound in a specific layer that I want to save, outside of the snapshot for whole project.

What I would like would be to have another option in the layer menu - “save layer patch” or something like that. My idea at this point is to simply save the .lv2 data that is saved anyway as part of the snapshot, but to a separate file, which can be accessed when selecting patches, with a special bank (“My patches” or whatever).

This obviously would only work for lv2 plugins, but it would still be great step forward.

The other day, I had come up with this great obxd patch, and started up VNC to save it using the plugin’s own UI. While this was eminently possible (incidentally, it seems that obxd saves its patches in the .lv2 format), I couldn’t figure out a good location to save the patch so that it would show up in the patch list when subsequently selecting patches in a layer.

I haven’t dived in enough to discover if the list of patches selecteble in the layer UI has actually been converted from the native obxd format at some point, and if so, how to convert additional patches saved from the obxd UI.

Indeed, it really is something that is missing.
So much so, I sold my Zynthian on Reverb.
I found that while it sounded incredible, it wasn’t very useable in regards to saving and recalling sounds. So frustrating to create a killer sound only to either loose it or save it “somewhere” 9 screens and 22 button pushes deep.
I hope the usability of the Zynthian improves, if it does I’ll be back. I put the money I got towards a Korg Krome.


Welcome to the wonderful world of success.
I’ve watched this area grow and develop and it’s almost more of an informational problem than a specific issue with the zynth. We, perhaps, are an area where the issues become visible.
I will of course, throw in the limited resource issue because that’s always there.
It’s the flexibility that is at the root of this.
Within a specific manufacturers device boundaries are clearly defined. However, in the open source world of zynthian , we have potentially, and to the great delight of many, a much richer jack audio environment to describe.

The grabbing of snapshots links and the maintaining the current state is designed primarily for stage use, a shot box it you will.It produces a complete jack environment and places control mappings in the GUI in the correct place so that the Engine renders up the right sounds and the correct MIDI controller mappings.
It’s the complete state of the model you are keeping and it’s functionality is often at odds with the rather more relaxed studio environment where you wish to establish a more granular approach to your creation.
Once you have that really nice seashore effect built up from a fluidsynth sample with helm wind and wave effects all driven by the zynseq you want to store it in a fashion where it can be rendered up with considerably more flexibility. On stage you want the whole rig to be loaded, The piano on layer one, the string synth on layer two, the bass pedals on layer 3 AND the seashore on layer 5 ) bang one button fast as it can be done. And that’s what the zynthian snapshot offers.
However which sound sculpting,our seashore wants to be able to load back into any layer ( are we still referring to mixer channels as layers?). So it can become that interesting sound blob, that can be passed around the zynth community, or indeed between different zynths in your rig. The ability to pass stuff like that around within a multi zynth rig, means you can locally monitor and remotely drive the same seashore sound for example.
So are we describing a more granular snapshot entity that is presented as a channel in the environment that’s building in testing?

Ideally these would be bound up as lv2 entities so they can be easily fed back into the Zynthian infrastructure that can be easily loaded in, and you also generate the meta data that allows so much decent introspection in large data sets of similarly structured data., or libraries as we used to call them in the videotape days.
It then becomes a naming exercise and zynthian does try to default to a sensible approach, but in the end it really would boil down to a localized entity and the ability of the zynthian infrastructure to detect it’s availability. ( A file with ANOTHER extension…).

This is all really unifying around the new GUI presentation (at present in the testing branch)

and we are involved in the channel naming we ultimately display, and the display of the OVERALL snapshot as the Mixer naming. We did try changing this but it just defaulted to default which wasn’t entirely helpful , so the question went on the back burner.

The exact implementation is needs to settle on a zynthian GUI screen actions, and the BOLD hold on the LS ( top Right) encoder with take you through to the snapshot quickly and you can handle the basic housekeeping that will ultimately arise as soon as you start doing a lot of sub snapshot construction.

Now is a good time to describe use cases and requests in this area. And having a bit of a look at what lv2 offers in the audio world is time well spent.

As ever, please disagree with vigour!

Well, I think I wasn’t thinking on so grand a scale really, just wanted to save patches that I’ve created for a specific synth.

I guess it sortof depends on how you view the Zynthian. One way of course is the total instrument view, where the snapshot captures the whole state of the instrument. Another view is simply as a standalone hardware plugin host, with a unified and tactical parameter editing environment. In this second view, I can load up any patch from a bank of existing (or uploaded presets), edit to my hearts desire, but actually not save it in the same format, which seems rather lopsided. Even with the first view, Zynthian tends to be a collection of preset banks, which can be tweaked, but not really worked with, as all tweaking starts with the presets.

To me, there’s so much that Zynthian has got right: the layered approach, with easy patch selection, and the patch name been shown in the layer name, the four-at-a-time tactile editing feature with intuitive and fast navigation, but there is no way to actually create a new patch adding to the ones already there.

To give an example: One of the main reasons that I bought my Zynthian was as a hardware host for ZynAddSubFX. Zyn is so complex that it’s not viable to edit directly from the front panel; indeed, only the part parameters can be edited using the Zynthian UI, which is probably a good idea since the sheer number of parameters would be ovewhelming. Consequently, I use an external tablet laptop running the Zyn-Fusion UI for editing, and thanks to a fairly recent patch which I think ended up in testing, ZynAddSubFX is started in such a way that the default path when saving via the Zyn-Fusion UI happens to be /zynthian/zynthian-my-data/presets/zynaddsubfx, where I can easily navigate to my own bank, which is later eminently accessible if and when I create a new ZynAddSubFX layer and want to use the patch I created.

So I’m seeing this feature not so much as a general “save subsets of snapshots for later use”, which certainly would be an interesting goal in itself (for instance if one wants to copy a whole layer, including all effects processing, to another snapshot), but rather specifically complementing the patch selection procedure which a simple way to actually write patches as well.

A first step along this way would be to set up the individual synth engines in such a way that saving patches via the engines’ own UI (i.e. via VNC) actually saves the patches in a format and location where they can be subsequently accessed when creating new layers. The second step would be a way to do this from the Zynthian UI iteslf.

I seem to recall (not having my Zynthian in front of me atm) that via the webconf it’s possible to add subdirectories for ZynAddSubFX patches, but it’s not a generally available feature for all engines; for obxd, it’s possible upload new banks, but not just create empty ones for saving new patches to.

1 Like

It’s not so much a grand scale as stepping carefully. To produce a lot of various file formats to cover all the possible configurations will lead to even more confusion than the present situation and that what we are keen to avoid. Certainly there is granularity around a specific engine and it’s own file formats will accommodate such an eventuality but the handling of chains of audio components seems to be a considerably more developing theme and as such do we treat that as a separate entity from the GUI’'s perspective?

I can certainly appreciate the ‘stepping carefully’ approach, in order to get a stable and sustainable ecosystem. Indeed all the good parts of Zynthian would seem to be a result of that sort of approach.

I would say that patch saving within synthesizer engines is quite different from the handling of chains of audio components, and both would have their usage. The latter to me seems like a subset of snapshots, with a layer granularity, whereas the former seems me more to be part of the adaptation of synth engines to fit within the Zynthian ecosystem (or vice versa - adapting the Zynthian ecosystem to handle not only the selection and editing of patches, but also writing them).

In my mind, I’m thinking having two additional options in the layer menu: “Save engine patch” and “Save layer”. Or perhaps, “Save layer” should be in the layer menu, whereas “Save patch” should be a special entry in the list of available patches for each engine, similar to the way “Save new snapshot” is at the top of the snapshot list. This would clearly separate the “save layer” function from the “save patch” function also in the UI.

I think sound design, in the way you’ve described it, would always be better done on a workstation with a midi controller. Even if that workstation is a raspberry pi. It’s possible the zynbox project would be better for that but I’ve not looked at it.

Well, yes, from a pure functionality point of view, but in practice it’s rather daunting in terms of workflow, if one happens to come up with a great patch during a Zynthian session, and then having to duplicate it in another environment just to save the resulting engine patch for reuse.

Occasionally I have specific sound designing sessions, but more often than not, sound design happens on the fly when working with a musical project.

It’s interesting though the view that the Zynthian is a performance-only tool with minimal tweaking of presets only to be saved in snapshots. Given the excellent editing capabilities, I’ve never thought of it that way; on the contrary I think patch editing is of the great features of this platform.

In contrast, with few exceptions (ZynAddSubFX being one), I find editing patches on a computer a pain, and doesn’t become much better with a MIDI controller such as a Behringer BCR2000 or Stereoping because the knobs are for me too mentally disconnected from the parameters they control.

So given that saving patches for engine is within the reach of the Zynthian, I don’t think it’s something that should be actively inhibited. I do realize now that the focus on development is elsewhere though, and at least it’s clear that the functionality does not yet exist and it’s not just something I haven’t managed to find in the current UI.

Zynthian is configurable and flexible. This results in it being used by different people in different ways. Many have enjoyed the advantage a self-contained box provides over a computer / laptop setup for live performance including rehearsal. Others have enjoyed the flexibility and expansive capabilities within a studio environment. I wouldn’t say it is aimed at stage use only but maybe that is the most common use that matches many workflows.

We are trying to expand its capabilities and particularly workflows to allow easier / more comfortable sound design, live performance, etc. As @wyleu says, with limited resources we must be selective in where we target effort and be (more) efficient with those resources. One example of where sound design workflow has improved is the provision of VNC accesss to the sound engines’ naitive GUIs. There is also work to improve the workflow for saving and recalling presets. (It is currently a bit awkward as described elsewhere in the forum.) We do plan to provide more intuitive preset management. It is currently inconsistent and often difficult to use. (It is kinda there if you roll up your sleeves but that is not what you arty folk want to do!!!)

Please bear with us whilst we improve this area. It is coming, maybe fairly soon… but then time is a cruel mistress that taunts and tempts but so often dissapoints. Let’s hope she is kind to us this time.

1 Like

@Jofemodo, maybe we could have a snapshot loading feature like follows.
If you move a snapshot that contains a layer of the engine into the preset folder, a default preset will be loaded and the preset parameter values of the snapshot will be taken.

1 Like

BTW, did you note that when saving a preset from the Jalv-gui menu (VNC), it’s saved on the right place now:


so it’s available after clicking the webconf’s “Search for new pugins and presets” button? OK … I will improve this part too :wink:


@mheidt , i will think about it …

So there is a way of saving presets for lv2 plugins at least then, even if only accessible via VNC? When I start the engine VNC, I can’t find any jalv gui there though.

You must have VNC enabled before the engines launch. Enable VNC in admin menu / webconf then reload the snapshot or restart the device.


Is this only in Testing?

Yes, testing branch

I wonder what I’m missing here. I switched all zyn* branches to testing, enabled VNC, and rebooted, but none of the running applications appears to be jalv or jalv-gui.

Did you perform a software update after switching to testing?

Could you send a screenshot of your vnc view?

This is after changing to testing, and then upgrading.

(I’ve minimized all the running engine UI windows to minimize the clutter:)