I recently started editing some ttl from lv2 plugins, getting started with RipplerX and regrader.
Now I tried to get into Odin2, which was a little harder because of the 259 parameters. I also did not finish the parameter order inside a group and left this to default by now. But it’s far more usable in the current state already. It is not quite perfect, but a good starting point. I also attached a file for TAL Reverb 3.
The thing is, I don’t really know Odin 2 so well and had some hard time figuring out what the parameters really do, which were:
all these reset parameters
the “FilterN OscN Input” parameters
the OSC Step* parameters
Some parameters might not be usable so well, because they refer to e.g. filter types which aren’t switchable from the UI. Maybe we can have a general discussion how to deal with these parameters which are less usable from the native UI. In fact it seems that some basic concepts like choosing waveform, osc type or filter type are not exposed as a plugin parameter.
Maybe you might want to have a look into it. (You’d have to put the folders inside /zynthian/zynthian-data/custom-lv2 and update, but backup the original file in /usr/local/lib/lv2 and keep in mind you have to delete them manually in case it will be included in the repository) Maybe someone knowing the synth better than me might want to suggest some better ordering for some categories.
Also about the discussion: A gew weeks ago I looked into the file of our beloved SurgeXT and ran into some problems:
Here we have some over 700 parameters
On preset load they are not updated, so the UI doesn’t reflect the state
We have a bunch of parameters which we might never want to edit from the native UI (8 LFOs or more?)
There are a bunch of parameters which are used for different purposes depending on the configuration. E.g. the oscillators parameters labels (as far as I remember) refer to the analog osc choice and have completely other purposes if another osc type is selected, but the parameter labels will not be updated.
So how do we deal with that? Do we try to erase parameters which we might not use? Do we have to have a set of parameters for 8 LFOs, a double set for both “Scenes” and so on?
I’d say we could reduce the set to Scene A, 2 LFOs and lift the controls for filter A to the top of the controls to be more accessible. This might be lead to a more usable native UI interface. LFO 8 and the likes would be for the ones who prefer to leave the VNC on.
Surge uses a brilliant technique of assigning modulation to each parameter which uses the same knob for both the parameter value and the modulation amount from each modulator source. Basically, any parameter may be modulated by any modulator. (Check out their naitive UI. It is an excellent design principle.) This is a fantastic way to allow extreme flexibility within a UI. This does not scale well to external controls like hardware controllers or zynthian. I have avoided too much consideration of how we could fully control Surge. It is a daunting task that may require substantial change to zynthian which seems excessive for just one synth, even if that synth is excellent! (I think they did something similar with Helm.)
Yes, the native plugin is brilliant. I didn’t expect the whole modulation thing being accessible on zynthian. I actually at least wanted to order the parameters in some meaningful way and thought how to get at least access to some VIP parameters (macro/filter/adsr).