[ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of fixes

Discuss running non-Linux applications and plugins on Linux, for example via wine

Moderators: khz, MattKingUSA

robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

[ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of fixes

Post by robbert-vdh »

The latest release post can be found here:

[ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fixes

The original release post for yabridge 3.1.0:

[ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

yabridge is a modern and transparent way to use both 32- and 64-bit Windows VST2 and VST3 plugins on Linux as if they were native Linux VST2 and VST3 plugins.

I realize I've never done a proper release announcement for yabridge here outside of the call for testers before yabridge 3.0's release, so here is one! This is mostly a bugfix update, but this release does add a few small features and it also adds support for using 32-bit Windows VST3 plugins. The other important fix is a workaround for a bug present in Wine 6.5 and Wine 6.6 that would prevent yabridge from exiting.

A full changelog with an exhaustive list of changes, improvements and fixes can be found here:

https://github.com/robbert-vdh/yabridge/releases
Last edited by robbert-vdh on Tue May 04, 2021 8:37 pm, edited 4 times in total.
Kott
Established Member
Posts: 439
Joined: Thu Mar 21, 2013 12:55 am
Location: Vladivostok
Has thanked: 2 times
Been thanked: 5 times

Re: [ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

Post by Kott »

Hi!

I got weird error with building package in Open Build Server. Not sure either the problem in yabridge, vst3 or wine:
[ 8s] [31/490] Compiling C++ object libvst3_base_wine_64bit.a.p/subprojects_vst3_base_source_fbuffer.cpp.o
[ 8s] FAILED: libvst3_base_wine_64bit.a.p/subprojects_vst3_base_source_fbuffer.cpp.o
[ 8s] wineg++ -Ilibvst3_base_wine_64bit.a.p -I. -I.. -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++2a -O3 -fPIC -isystem../subprojects/vst3 -isystemsubprojects/vst3 -DRELEASE=1 -DNOMINMAX -DWINE_NOWINSOCK -m64 -Wno-cpp -MD -MQ libvst3_base_wine_64bit.a.p/subprojects_vst3_base_source_fbuffer.cpp.o -MF libvst3_base_wine_64bit.a.p/subprojects_vst3_base_source_fbuffer.cpp.o.d -o libvst3_base_wine_64bit.a.p/subprojects_vst3_base_source_fbuffer.cpp.o -c ../subprojects/vst3/base/source/fbuffer.cpp
[ 8s] In file included from ../subprojects/vst3/base/source/fbuffer.cpp:40:
[ 8s] /usr/include/c++/10/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
[ 8s] 75 | #include_next <stdlib.h>
[ 8s] | ^~~~~~~~~~
[ 8s] compilation terminated.
[ 8s] winegcc: /usr/bin/g++ failed
[/code]

maybe you have any thoughts?
robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

Re: [ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

Post by robbert-vdh »

Kott wrote: Thu Apr 15, 2021 11:28 am Hi!

I got weird error with building package in Open Build Server. Not sure either the problem in yabridge, vst3 or wine:
<snip>

maybe you have any thoughts?
Wineg++ on Wine 6.6 appears to have broken the include paths. Someone else also ran into the same issue when trying to build yabridge on the Fedora COPR, which also had Wine 6.6 installed. There's a Wine bug report for this here. For now you'll probably have to find a way to downgrade the installed Wine version on the build server to some version between 6.0 and 6.5 to build yabridge, unless you can figure out a workaround for this wineg++ issue.
Kott
Established Member
Posts: 439
Joined: Thu Mar 21, 2013 12:55 am
Location: Vladivostok
Has thanked: 2 times
Been thanked: 5 times

Re: [ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

Post by Kott »

thanks for the tip and link!
Toejam76
Established Member
Posts: 45
Joined: Sat Jun 20, 2020 10:41 am
Has thanked: 4 times
Been thanked: 2 times

Re: [ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

Post by Toejam76 »

Very cool! It did indeed fix a lot of things. Korg Legacy Collection is finally recognized and runs very smooth All the FabFilter 2 plugins work as expected.
I can run it on wine 6.6 staging and plugins load super fast and take waaaaay less memory (several hundred MB) than hosted in Carla, which makes a big difference for startup loading times and general usage because I had like over 20 instances.

However some plugins crash Reaper instantly or cause it to hang with a bunch of zombie threads.
Emulator X3 (x64) standalone works (x86 not) - yabridge converted it, but it doesn't show up in reaper. Carla showed for the first time I saw it a error message "plugin timed out or not responsive".
STL Emissary and NadIR - instant crash, both yabridge and Carla
Plogue AlterEgo - big DSP spike in Carla then disabled, instant crash with yabridge. With wine set to ALSA running from console it says driver might not support samplerate, with PULSE it just crashes with a wall of error messages.

Rolling back to wine 6.4 didn't change anything, so I suspect something else is going on, because all those plugins worked before on the previous Ubuntu version. I can't install mono-complete for instance, because of unmet dependencies. I also wasn't asked to install gecko or mono after installation of wine.
That's on me because I had to be adventurous and install Ubuntu Studio 21.04 Beta, so I don't want to complain.
On the upper hand yabridge works like a breeze with the functional plugins and makes my template much more efficient.
robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

Re: [ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

Post by robbert-vdh »

@Toejam76 Great to hear that things are working now! If Emulator X3 also doesn't work properly under Carla, then it's most likely just a Wine issue we cannot solve on yabridge's side. Same with those other plugins. If they don't statically link their MSVC++ runtimes, then you may have some luck installing vcrun2019 through Winetricks, but that likely won't help. You can also try installing those plugins to a clean Wine prefix and see if that helps. Do make sure the WINEPREFIX environment variable is not set when you launch REAPER when you do though.
Toejam76
Established Member
Posts: 45
Joined: Sat Jun 20, 2020 10:41 am
Has thanked: 4 times
Been thanked: 2 times

Re: [ANN] yabridge 3.1.0, with 32-bit bitbridging for Windows VST3 plugins

Post by Toejam76 »

Funny thing is, it does work in the Windows version of Reaper with wine which I keep as a fallback if anything else fails. But now it crashes too with some plugins and have audio dropouts. The Windows Installer msi also doesn't work anymore. I am going back to the "groovy gorilla" and see if that works.
"Never change a running system" or something like that...

[EDIT] Everything works again with wine 6.7 and yabridge on Ubuntu Studio 21.04. Even the "problematic" ones.
[EDIT2] Found out that Carla can load some incompatible plugins after they were converted with yabridge even if Reaper doesn't recognize them or crashes. Looks like Carla and yabridge is a great combo to run a lot of stuff. It's a little more overhead, but whatever.
robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

[ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of fixes

Post by robbert-vdh »

(I'll just reuse this thread for new major release announcements)

This was supposed to be a small bug fix update, but here we are. First and foremost, this update considerably reduces the overhead of bridging VST2 plugins. If you have the choice I would still recommend preferring the VST3 version of a plugin over the VST2 version for the additional features and better out of the box scaling, but especially when using plugin groups VST2 plugins should outperform VST3 plugins by a decent margin now. I'll take a look at further optimizing VST3 plugin bridging in a next update. This update also comes with a lot of compatibility improvements and bug fixes, particularly concerning plugins that don't quite implement the plugin spec correctly or that make false assumptions about their environment. In addition, VST3 plugin compatibility with Ardour and Mixbus has also improved greatly.

On a side note, it may be a good idea to be aware of the fact that Wine 6.7 has broken the Spitfire LABS and BBC Symphony Orchestra Discover plugins (wine bug #51063). I would recommend pinning Wine Staging 6.4 for the time being.

A full changelog with an exhaustive list of changes, improvements and fixes can be found here: (and yes, this time the list sure is exhaustive)

https://github.com/robbert-vdh/yabridge/releases
Last edited by robbert-vdh on Tue May 04, 2021 8:37 pm, edited 1 time in total.
Toejam76
Established Member
Posts: 45
Joined: Sat Jun 20, 2020 10:41 am
Has thanked: 4 times
Been thanked: 2 times

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fi

Post by Toejam76 »

Cool beans! Using the cursed wine 6.7 more plugins load directly in Reaper now like EmulatorX3, all FabFilter plugins and sforzando.
One little thing: the Korg Legacy Collection crashes Reaper at startup when it find the converted MidiFilter,so and mixer3.so in /Program Files (x86)/Common Files/KORG/Plug-Ins/VST. After removing them, starting Reaper, closing it and adding them again everything works.
robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fi

Post by robbert-vdh »

Toejam76 wrote: Tue May 04, 2021 8:08 am Cool beans! Using the cursed wine 6.7 more plugins load directly in Reaper now like EmulatorX3, all FabFilter plugins and sforzando.
One little thing: the Korg Legacy Collection crashes Reaper at startup when it find the converted MidiFilter,so and mixer3.so in /Program Files (x86)/Common Files/KORG/Plug-Ins/VST. After removing them, starting Reaper, closing it and adding them again everything works.
I don't know why those KORG plugins would do that, but the obvious solution would be to just move either those two plugins or the other plugins to another (sub) directory. That should work.
Toejam76
Established Member
Posts: 45
Joined: Sat Jun 20, 2020 10:41 am
Has thanked: 4 times
Been thanked: 2 times

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fi

Post by Toejam76 »

Maybe because they are internal plugins of that software and not really proper VST plugins, but recognized as such. I haven't tried it, but I think those are not meant to be used independently.
robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fi

Post by robbert-vdh »

If yabridgectl creates .so files for them, then they are at least real VST2 plugins. Yabridgectl actually checks whether files are actually VST2 and VST3 plugins before setting up yabridge for them.
User avatar
GMaq
Established Member
Posts: 1872
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 20 times
Been thanked: 14 times

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fi

Post by GMaq »

Hi again @robbert-vdh

Just wondering if /usr/local/lib/vst3 will work and can be integrated into yabridge?

For example when I prepare AVL-MXE ISO's nothing can be in User's home and must be in the filesystem. I distribute some odds and ends demos and plugins that aren't in repos (yet) and this includes some LinuxVST3 and some WindowsVST2 as proof of concept. My solution to keep everything straight so far is to put all native Linux stuff in /usr/lib as expected and the relatively new Linux VST3 plugins work perfectly in /usr/lib/vst3/. I place Windows VST2 plugins in /usr/local/lib/vst.

Sooo... If I start using yabridge and distributing it I would want any Windows VST3 Plugins to go in /usr/local/lib/vst3 to differentiate them from the native Linux VST3's in /usr/lib/vst3 would this work and could that PATH be included?

Just wondering..
robbert-vdh
Established Member
Posts: 45
Joined: Mon Mar 01, 2021 10:56 pm
Has thanked: 9 times
Been thanked: 8 times
Contact:

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of compatibility improvements and bug fi

Post by robbert-vdh »

Hi @GMaq!

So yabridge and yabridgectl handles VST2 and VST3 plugins slightly differently. Since it's by far the simplest and most flexible approach, for bridging VST2 plugins yabridgectl simply creates .so files next to the original Windows VST2 plugin .dll file. Meanwhile, VST3 plugins are only allowed to be installed to a few specific locations, so yabridgectl will always set those up as merged VST3 bundles in `~/.vst3/yabridge` in the user's home directory. So yes, you could preinstall some Windows VST3 plugins to for instance `/usr/local/share/wine-vst3`, and then as long as that directory gets added to yabridgectl they they will be set up and ready to use when the user runs `yabridgectl sync`. I would advise against using `/usr/local/lib/vst3` though, since mixing Linux VST3 bundles and the older-style Windows .vst3 modules can trip up certain DAWs like REAPER when they try to scan those plugins.

Now, I can think of two potential issues with bundling Windows plugins like this in /usr/local. First of all, a lot of plugins rely on shared data that's normally installed to the Wine prefix (for instance, in `~/.wine/drive_c/ProgramData`). A second minor issue is of course that yabridgectl needs to know to look for plugins in this `/usr/local/share/wine-vst3` directory. The obvious solution to both of these things would be to use a skeleton. I don't know if AV Linux already does this, but on files in /etc/skel are automatically copied to the home directory when creating a new user. So you could create a skeleton that contains a Wine prefix where those VST2 and VST3 plugin demos are already installed (the prefix could be placed in `/etc/skel/.wine-avl` to prevent conflicts with a user's own Wine prefix), a yabridgectl configuration file to tell yabridgectl where the VST2 and VST3 plugins in that prefix are (after it's been copied to the user's new home directory, of course), and potentially even a symlink from `~/.wine-avl/drive_c/Program Files/Steinberg/VstPlugins` to `~/.vst/wine-avl` so that the Windows VST2 plugins are also automatically found by every DAW. This approach does of course waste a bit of disk space since there are now two copies of that Wine prefix (in both `~/.wine-avl` and in `/etc/skel/.wine-avl`), but it does mean that everything's all set up and ready to rock out of the box without any non-standard configuration. Just wanted to throw this out there, because I don't know if you had already considered using /etc/skel for things like this!
User avatar
GMaq
Established Member
Posts: 1872
Joined: Fri Sep 25, 2009 1:42 pm
Has thanked: 20 times
Been thanked: 14 times

Re: [ANN] yabridge 3.2.0, with greatly reduced VST2 bridging overhead and a lot of fixes

Post by GMaq »

Hi, thanks for the reply!

Yes I do use /etc/skel it is mostly to load session default configs like system theme, wallpaper, conky, window manager settings and on and on.. As you can imagine every system thing you tweak that you want to preload for a new User installing has be duplicated perfectly in /etc/skel and any incremental updates and changes have to be kept track of and placed there which is one of the most time consuming things I do..

I also know that things like fonts, Manuals, and yes Audio plugins or wine prefixes could be preloaded there but it really becomes extra complicated and you have Users with stuff preloaded in their home which appears in a Repository a month later or they install a new version perhaps unaware that the preloaded one is there and then you have duplicated plugins...on and on! That's not a road I want to start going down because I'm not able to work on AVL consistently and keeping track of every plugin upgrade etc etc. would be an impossible task (for me anyway).

I really should get out of the Plugin business completely... have Wine-Staging there... have the bridging there and let the User place their own plugins in their home folder and just let your stuff work like it defaults.. Sometimes we start things to make it easier and down the road it becomes a pretzel..
Post Reply