TLDR: a bug in VST3 scanning on Linux causes Waves plugins not to load. The actual VST3 .so name is being truncated at the first ‘.’ instead of the last one. A scan inside “WaveShell1-VST3 15.0_x64.vst3” causes it to look for “WaveShell1-VST3 15.so” which doesn’t exist - it should be looking for “WaveShell1-VST3 15.0_x64.so”. It is missing the “.0_x64” in the middle.
Description
(Relevant log file details at end.)
Waves Windows VST3 plugins do not appear at all in Renoise on Linux, due to the files not being scanned correctly. As the log files show, this appears to be due to a filename truncation bug, causing it to search for a non-existent file (and hence, dlopen fails when attempting to load the non-existent .so files).
VST3 plugins from other vendors load fine (both native Linux and Windows VSTs via WINE/yabridge), suggesting this isn’t a problem with Renoise settings.
Waves VST2 plugins do load on Linux in Renoise, so this seems to be VST3 specific.
The Waves VST3 plugins do load in Reaper 7.22 with the same yabridge, suggesting this is a Renoise bug rather than a WINE or yabridge issue.
Install Waves Central via WINE and install some VST3 plugins (eg Curves Equator, which is v15 / VST3 only)
Run the yabridge sync to create Linux stub .so VST3 files: ~/.local/share/yabridge/yabridgectl sync
Run Renoise (I’m on v3.4.4)
Despair, where are all my VST3 Waves plugins, cry
Expected Results
All the VST3 Waves plugins I own should be listed in the bottom-left plugins directory
Actual Results
No VST3 Waves plugins are listed.
Logs
Vst3Plugs: Instantiating: /home/myusername/.vst3/yabridge/WaveShell1-VST3 15.0_x64.vst3…
Vst3Plugs: Failed to load module: dlopen failed.
/home/myusername/.vst3/yabridge/WaveShell1-VST3 15.0_x64.vst3/Contents/x86_64-linux/WaveShell1-VST3 15.so: cannot open shared object file: No such file or directory
Vst3Plugs: Instantiating: /home/myusername/.vst3/yabridge/WaveShell1-VST3 15.2_x64.vst3…
Vst3Plugs: Failed to load module: dlopen failed.
/home/myusername/.vst3/yabridge/WaveShell1-VST3 15.2_x64.vst3/Contents/x86_64-linux/WaveShell1-VST3 15.so: cannot open shared object file: No such file or directory
From your description, it seems that the . (dot) seems to be poorly handled.
If there is a first dot in the filename of *.vst, it appears to blindly use the filename up to that point to look for a *.so of the same name.
Maybe this won’t make any difference, but just to be sure, do you close Renoise, rename the following file, start Renoise, and scan again, and is it the same?
Tried that! No luck when deleting the VST3 caches and scanning again. Thanks for the suggestion though.
Your update matches my thinking, and I think you’ve explained it better than I have.
It also means there is a “workaround”:
Workaround
In .vst3 folder, rename the folder “WaveShell1-VST3 15.0_x64.vst3” to “WaveShell1-VST3 15.vst3”
Inside that folder, look inside “Contents/x86_64-linux/”
Rename the “WaveShell1-VST3 15.0_x64.so” there to “WaveShell1-VST3 15.so”
Look inside “Contents/x86_64-win/”
Rename the “WaveShell1-VST3 15.0_x64.vst3” there to “WaveShell1-VST3 15.vst3”
I just tried that, and it “worked” - Renoise is able to find and scan the Waves VST3s in that specific WaveShell, as long as there is only one dot in the foldername and the .so / .vst3 files are renamed accordingly. The UI resolution is wildly wrong though (dialogs are scaled way too big, only top left is visible), but at least the Waves VST3s actually load.
I think that confirms there’s a bug in the handling of a . (dot) character in the VST3 folder filename. (And only with VST3, it’s fine with VST2.)
Waves have been so troublesome to install and maintain for many years so when Waves Central from one day to another stopped working I decided enough is enough and uninstalled despite having at least over 30 of their admittedly quite good plugins.
Waves should provide their legacy/old version plugins through Waves Central and make sure that central app is actually working properly. Until then it stays off my machine.
This is actually a bug in the VST3 SDK, so it may also be broken on other Linux hosts. I’ve filed a report here:
As a workaround for now, as you’ve already tested yourself, please remove the dot from the bundle name and from the .so file. This should not break anything else.
Oh wow! I never considered it could be a VST3 SDK bug. Thanks for tracing this all the way back & filing the bug with Steinberg, taktik! Thanks also for renaming the thread to the actual bug too. You’re awesome!