You don’t need to rescan plugins. Check with the synthv1, for instance. you will see that the controller screen list, that before were shown as a numbered list, now it’s shown as named groups that have sense from a “sound design” POV. As i commented above, currently only a few plugins use this feature, but we can add the group info (ttl) for the rest, and everything is LV2-wise.
Also, as you have notes, the controller screen list format has changed a little bit:
When there are FXs on the chain, the controller screens from different chain elements (plugins) are separated with a “title bar” instead of adding the plugin name as prefix on every row. This saves some horizontal space so the group info can be better displayed.
Woaooo! That’s great! Pushing changes upstream is the better option, so +1 to your PR on RaffoSynth. Anyway, this is not going to work on all cases, so we should have an alternate way:
Forking. Not my favorite, specially for those plugins that we install from repo (deb package).
Applying the changes on zynthian, as a patch.
What do you think?
BTW, i will add groups to OBXd ASAP. Somebody wanting to do it for Dexed?
No, I was looking to open it up on the desktop to map groups properly and went to the official page and saw it, it’s a new version so maybe our needs updating
Regarding forking or whatever, I’d honestly just try to pull things from repos when available, and patch them if need be with our own tweaks. In my opinion maintaining a patch is way easier then maintaining a fork, but I’ve not got a ton of experience either way. I actually really like the way modui does it, where they add their own layer, a “patched by design” sort of thing. It does create more friction when adding new plugins but I think integrating the ones we already have brings more value then adding more and more. And if any new plugins are worth it then they’ll probably get the work on them
Please, update before. I’ve improved some details about how controller screen names are generated.
As you can see, i’ve totally refactored the TTL and added ScalePoints to lots of parameters, so now you have selectors with options, ON/OFF boolean controllers, etc.
I couldn’t fix the ordering because the UI use the port “index” for binding the widgets with the control ports. Also, i think there is some parameter with bad name or wrongly assigned.
Finally, there are a few parameters ungrouped because ican’t find them on the GUI and i don’t know what the hell they do Somebody could help with this?
OK! the feature is merged on testing and i’ve included the 2 custom ttl files we have generated until now. So the list of plugins with grouped controllers is:
obxd => to improve!
raffo
synthv1
samplv1
patchv1
drumkv1
amsynth
MDA JX10 => partially grouped!
MDA DX10 => partiallly grouped!
simply update on testing and give it a try!! If you changed to devel branch “ctrl_group”, it’s time to change back to testing.
I hope more custom ttls will be coming very soon. Some volunteer for working on these:
Dexed
Noize Maker
Helm
YC20 Organ
Calf Monosynth
DrumSynth
Fabla
Nekobi
String Machine
Vex
etc.
Of course Audio & MIDI FXs are also good (and probably easier) targets. Choose your favorites and contribute with a good “controller grouping”!!
When connected via VNC using a QWERTY keyboard to control the Zynthian, after pressing Enter to enable select mode the selection keeps jumping back to the top of the list.
But is the folder read? I tried to add Pianoteq config to that folder but it did not change behaviour so I had to change the config in /zynthian/zynthian-plugins/lv2.
The “update_zynthian_sys.sh” script, that is run when you make config changes or update software, copy the content from this directory to the LV2 directories.
So, for devel/testing i recommend you copy the file directly to the LV2 directory. When the ttl is ready, copy it to the “zynthian-data/custom-lv2” directory and commit/push.
Also something that i’ve noticed is that the raffosynth.ttl that is read is not the one on zynthian_plugins folder but in usr/lib/lv2/raffosynth.lv2
This is kind of inconsistent, as there is a raffosynth file in the zynthian_plugins folder but it does not seem to get read (maybe another script like the one you mention takes care of this?) and also there are some synths that only appear in /usr/lib/lv2
I think it would be really benefitial to have this be the same for all plugins and have some docs in the wiki about it (I could write them myself) as this would allow for easier contribution in the groupings.
One think to keep in mind if we’re already using a folder to patch synths is that maybe then having some zynthian-specific *.ttl files might not be that much of a stretch, and might allow for some more options regarding UI and control screens.
Plugins are installed in different locations and it’s not easy to totally control that. A lot of plugins are installed from deb packages, so they get installed, normally, on “/usr/lib/lv2”.
Some others are built and installed from source, some of them on “/usr/local/lib/lv2”, and some others to “/zynthian/zynthian-plugins/lv2”. We could unify these 2 locations, but i don’t see a big advantage by doing so, and it would takes time and effort.
Normal users don’t need to know where plugins are installed. We can implement (it’s almost implemented) a mechanism for allowing to extend/patch installed plugins.
Maybe sym-linking the two directories (/usr/lib/lv2 and /home/pi/zynthian_plugins/lv2) before setup could mean less duplication and more cohesive behaviour. I do agree that normal users need not be concerned about this things, but any developers that might want to contribute might be deterred if there’s no obvious way of finding stuff.
The extension/patching system seems like the way to go, but maybe having 3 files in the filesystem called the same is a bit misleading? (It feels like that to me), so maybe patches could have a prefix or suffix (zynth_*.ttl or *_zynth.ttl) to differentiate them from the original files, and we can unify files so that there’s not duplication where it isn’t needed.
Somebody could help with this?