Multiple Headless link-instances are ignored by reaper

[rafjagger]

I followed the readme.md instructions for headless configuration:

I export the Presetfolderpath to .bashrc

I made three links like so: ln -s -T oscsend-light.so oscsend-light-track-1.so

I checked that the corresponding track-1-3.yaml are in the presetfolder.

I gave reaper the pluginfolder as vst-path and let it scan for new plugins. Reaper shows me the gui version and only one headlessversion, both with the same name.

The headlessversion do not send osc-data (Offcourse I set port and ip in yaml).

[rafjagger]

headless ardour ignored multiple links too.

Ardour Console after rescan vst: error: failed to expand CURIE `xsd:float'

[drlight-code]

Could you try creating copies of the plugin instead of symbolic links? With bitwig I sometimes observed weird behaviour when using symlinks, I assume that it could be related to the scanning code caching file timestamps or file checksums. It might get confused when symlinks are used instead of actual files.

[rafjagger]

After reboot reaper found the linked plugins but the headed one doesn't show the gui anymore. Also the headless ones still doesn't send osc and the names are still the same.

[rafjagger]

headless copies instead of links doing well.

[rafjagger]

I could measure osc-data to get the right plugin names (in reaper they all named same). could rename them in the pluginwindow. Ugly but works

[drlight-code]

Regarding the use of symbolic links, I also encountered errors with Bitwig Studio. I removed the hint from the Readme file for now. I'm still figuring out a way to make the plugins show up individually and make them distinguishable. This for example works in Bitwig, because it seems it uses the actual filenames as plugin identifier internally, while Reaper and Ardour seem to use the reported plugin name.

[drlight-code]

So.. I finally was able to resolve this issue, hopefully. Unfortunately, the initial design that allows to just rename / symlink the prebuilt version of the plugin turned out not to be possible after all. This is due to how the VST3 API and its wrapper in JUCE work, where in particular the plugin name and unique plugin ID are hardwired at compile time, although the API suggests otherwise (at least regarding the plugin name).

Instead, I chose to pre-compile the plugin to load different presets at runtime. While this is slightly less practical because you always have to build the plugin once for each preset you want to use, this turns out to be quite convenient. I provided a build script which you can pass a list of preset names for which the plugin should be prebuilt. I updated the build instructions accordingly. If this is still relevant to you, I would be happy to see if this works for your scenarios @rafjagger @cancandan.

[drlight-code]

I just tested this in different hosts and it works fine in Reaper and Bitwig Studio, but Ardour still doesn't recognize the per-preset versions of the plugin. I have a clue why that is the case and investigate further. I'll keep you updated of the progress.

[drlight-code]

Good news! Ardour 6 on Archlinux is actually showing all plugins and everything seems to work fine. Before I was testing on Debian stable. The UI is a bit sluggish and when I close the editor view it crashes Ardour sometimes, but that's for another issue.. Furthermore, Ardour seems to ignore plugins that contains numbers in their name, so something like "track-1" as a preset won't work for now. I will investigate this further and fix this upstream in Ardour. Anyway, as long as you don't use numbers in the preset name things should work for Ardour in principle. If you want to give it a try please go ahead!