Controller menus & presets in LV2 plugins


I have a couple of questions about LV2 plugins like amsynth. Is there an easy way to modify the menu structure so that it would be labeled and more logically organized? I’m also wondering if it would be helpful for some to go through and reorganize the preset banks so that they make sense and incorporated into the zynthian version for everyone. I’m guessing editing the /zynthian/zynthian-plugins/lv2/amsynth.lv2/amsynth.tt1 file and all the bank tt1 files would do it.

However, I don’t want to spend too much time on it if it’ll be wiped out in an update and if it wouldn’t be something that could be pushed out to the community.

I guess I’m volunteering if I’m on the right track…



Hi @favolaschia!

Regarding the “reorganization and grouping” of LV2 controller ports (aka “parameters”), it would be really nice, but we can not modify the TTL files directly because it would be very difficult to maintain and upgrade. We have to add this information as a separated layer.

I think we should follow the LV2 specification for grouping, extending it with an index number for ordering:

We should add a new TTL file with the extra info and modify the zyngine code for using the new information layer when rendering the controller screens.

It’s a hard work, but we can do it, of course. Let’s do it … but first, let’s open the discussion with the community :wink:


It’s also possible we could submit these suggestions back upstream, it might benefit programs like Carla to organise the controller ports a little better.


Regarding the presets, it depends of the plugin. Some plugins include a “factory” preset collection in the LV2 plugin directory. Again, modifying directly the TTLs would complicate maintainment and upgrading.
Amsynth is one of this cases. In fact, it includes a really big preset collection, grouped in several banks. You should define your own bank/preset collection …


Regarding Amsynth and grouping control-ports, i just take a look to the TTLs and we are lucky, as it already define groups, so we only need to implement the second part of my proposal …



I agree this would be of significant benefit. Too many presets can be irksome, e.g. slow load time, difficult to navigate. A method of customising this would be good. Maybe a method within the webconf to organise presets and banks.

Regarding the order of parameters, this has been discussed before but hasn’t really made progress. It would be advantageous to have consistency where possible, e.g. for master volume to appear on the first page on the same knob for all synths. As said, this involves quite a bit of work to implement mapping layers and avoid excessive maintenance overhead but I think it is worth it.

I went through the Amsynth plugins tonight and collected the names of all the presets from the file and formatted it for a spreadsheet I sorted the spreadsheet by preset name, but provided a column that provides the name of the current bank where it occurs. This set is particularly messy.

Looking at the list, there probably is some duplication and a lot of presets in series that represent fairly small changes in an original patch. Eliminating some of this might help some of the issues @jofemodo brought up when Amsynth was added. Since the patches are basically text files, it shouldn’t be too hard to compare them and see which ones are different and how and come up with some criteria for what to keep (if we want to get rid of anything at all).

The other point here is that there are more than 2,000 presets in 21 banks and the banks and the presets are named cryptically, this makes it really hard to find things. It can be really difficult to find a patch you like if you don’t keep good notes of which bank and about how far down the list it is.

Personally I find a lot of good sounds in Amsynth, but finding anything is time consuming and locating things you liked again is difficult. I think it would be good if we could approach organization like in the presets for the LinuxSampler which categorizes presets into pretty logical groups like Bass, Brass, Strings, etc.

I really like the idea of editing the control groups so that they’re laid out better (this would be good for other LV2 plugins like Obxd too). I would really like all (or at least most) of the controls for the LFO to be on the same screen and have them be named nicely would be great too. I’m used to the fact that the master volume and LFO Frequency are on Amsynth#4, but it would be great if we could modify things to make it better to the device.

1 Like

Welcome to the success problem. One can admire the simplicity of a mini moog only one patch and you steered your way to it rather than just recalled it . . :smiley:

There is a strongly developing division of involvement. With the Mixer control we can provide our top level interface where the zynth community has control over positioning, which is Sensible. Knowing the top left, in which ever orientation we may settle on, is Output Volume is very handy to know.

Quite what may happen in the chaos down below in the Layers, is in truth anyone’s guess, and probably best left that way. By the time you add in the many different possible encoder options that could be available, for some of the many, many parameters we can see, then we will in some cases be doing little more that presenting a mapping.
In someways it’s a mistake to give things names, cos most people aren’t very good at generating decent names within namespaces.
I’d actually quite like a bunch of strings simply filed under a string sound with duplicates, if I could easily preview and grade them.
What you really want is fast audio reviewing, in lists that you can order many ways. To be able to sort by Attack, Decay Values for instance, and then tagging of those groupings, would allow people to pass back their view as minimum a ‘like’, a Shrug’ or a dislike, possibly. And at best of range value. . . .

If we could categorize properly then rather than comparing within engines we could compare across the whole set of sounds, so you could genuinely choose similar sounds produced in completely different ways. I don’t know if there is a world of C-Sound string pads but It would be interesting to put those in people hands who reach for a Solina at the moment. . .

Yes, but I think we need to do what we can to try to make some system that organized things better. Top level organization seems like it would be difficult to me at least in the current zynthian menu structure, but I don’t know enough.

It’s probably most sensible to work on the menu/control groupings first. If we had the interface so that you could quickly and easily set the parameters of the synthesizer it wouldn’t be so necessary to have many presets.

1 Like

if the zynthian-ui had its own rest service, we could write our own web-based UIs for each plugin.