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…
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
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.
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.
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 . .
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.
I’ve got a question regarding this, does jalv just manage lv2 connections or are they the ones to read and process the lv2 parameters?
I say this because maybe we can check for a zyngui.ttl file and have something similar to what modui does. If said file exists then read it and use it for controller setup, if not go for the default.
Hi @Pastitas, I am not quite sure what you are asking but will try to answer anyway .
JALV is an application which hosts LV2 plugins within a JACK environment. It runs the plugin, reads configuration / presets, presents audio and MIDI i/o to JACK, allows loading and saving of presets and adjustment of parameters. It can also host a GUI, either supplied by the plugin or a generic UI. We can of course create our own ttl files with presets and have done so for many plugins including Pianoteq, Surge, Vitalium, etc.
LV2 exposes controls with each having an index (integer) to identify it. I think Zynthian uses this to order the controls. We use a Python LV2 library to to access this which interprets and presents stuff in its own way. That extra layer of abstraction may impact our ability to sort controls but it is not beyond our wit to employ a mechanism for defining our own ordering. It would be good to avoid the overhead of an extra layer of abstraction which requires coding, configuration and ongoing maintenance but we may need exactly that!
I’ve been playing with the index of parameters and i couldn’t seem to get things ordered differently, so maybe i was editing the wrong file? (amsynth.lv2/amsynth.ttl)
I definitely agree that avoiding it would be the best but I do think this is what we need, a layer that allows zynthian to associate lv2 parameter’s order/midi control/parameter with zynthian controllers. This is being done now, but not in a controlled way, so maybe the extra config could be just optional? throwing ideas here, this does fit within my gui design and would be a required step for that development
