robbert-vdh
commented
3 years ago This is on my list of breaking changes to consider for yabridge 4.x, but either way is a compromise, so I don't think I'll end up doing this. I've explained why a couple of times on the Discord, but the gist is that doing this would actually make everything more opaque and less flexible. Storing these .so files right next to the Windows plugin files makes it very clear what's going on at a glance without even loading the plugin, and it also avoids a layer of magic. You can just add your VstPlugins directory to your DAW as if you were using Windows, and it will just work. If you for some reason really don't want to do that, then you can always symlink that VstPlugins directory to somewhere in ~/.vst and add that directory instead. There are instructions for this in the readme.
Some of the issues with automatically dropping a symlink to the generated .so file in a directory like ~/.vst/yabridge are:
- How do you differentiate between a 32-bit and a 64-bit plugin with the same name? You can't. You can add a suffix to one of those, but then those suffixes could in theory also clash with another plugin (unlikely, but less potential for issues is better in my opinion).
- What happens when you have a plugin with the same name provided by two different Wine prefixes or plugin directories, even if you only want to use the plugin from one of the Wine prefixes? I know I have duplicates of the same plugin set up in a couple of different prefixes that I only use for testing specific configurations (so I won't use them during normal usage), but I still want to keep those plugin directories added to yabridgectl. Right now for VST3 plugins we're forced to create the merged VST3 bundles in
~/.vst3/yabridgebecause the VST3 specification says that is the only valid place they can go in your home directory, but the VST2 specification does not have anything like that. So for VST3 plugins, we just throw a warning when this situation comes up and then pretend nothing happened, but it's not an ideal situation. - And of course, that whole opaqueness thing I mentioned. When creating those .so files right next to the plugin's .dll file, it's super obvious what belongs to what, and where the plugin is coming from. When you start putting them all in one place, it's not immediately obvious which plugin is going to run in which Wine prefix.
I've probably forgotten a few important ones. You can search through the Discord for more discussion on this!
udaemon
salut Robbert and people involved! thanks for this well working vst-bridge! I have finally found some time to test yabridge and it works very nice. the only thing that I found missing when setting yabridge up is the option to define a folder where the .so-files yabridge produces go (be they moved there or copied or symlinked). I know this already from airwave and linvst, so that's probably why I missed it. I'm not telling you have to adapt to these "standards" and maybe you've chosen to handle it differently on purpose. But from my perspective it is a very comfortable option: I would set /$HOME/.vst as link location so that my daw would automatically would find the new vsts.
do you think this is a good feature for yabridge? thanks and take care! christoph