robbert-vdh/yabridge 4.0.0

on GitHub

TL;DR: If you don't have the time to read the entire post, do make sure to still check out the first bullet under the 'yabridgectl' section of the changelog.

It's been a couple of months, but today's the day to finally release yabridge 4.0. The original plan was to also work on ARA2 support for this release, but most of these changes have already been sitting idly on the master branch since April as I didn't have any time to prepare a proper release in the meantime. So it seemed like a good idea to just get these things out of the way first, as there are a several significant quality of life improvements in here.

So, what changed? In short, almost everything. But, at least in theory, after the initial yabridgectl sync, everything should work exactly as it always has worked or better. All of these changes and many more are covered in more detail in the changelog. So if you're interested, then I encourage you to read that as well.

The biggest change in yabridge 4.0 is very technical, but it will improve the experience of using yabridge considerably. Yabridge has always consisted of two components: a plugin library a native VST2 or VST3 host can load, and a Wine plugin host application that can host Windows VST2 and VST3 plugins. Both components talk to each other to pass through messages or function calls, and they are thus coupled very tightly together. Because of that, updating one but not the other may result in crashes or other unexpected behavior. And as a result, you had to always rerun yabridgectl sync after updating yabridge in order to replace old yabridge library copies with fresh ones. This can be a problem when installing yabridge through a distro's package manager, as the package may have been updated without you realizing it. Yabridge would pop up a desktop notification warning you about this, but even that may not work if the old yabridge library copies were compiled against older version of Boost as the host would now be completely unable to load the plugin. To remedy these problems, yabridge 4.0 no longer copies the entire plugin libraries around. Instead, yabridgectl now using these new, dependencyless shim libraries while the main yabridge files stay in their place. These shim libraries are tiny plugins that simply search the system for the actual yabridge files, load them, and then forward all function calls to them. This somewhat resembles the chainloading process used by boot loaders, and yabridge thus borrows that term to refer to this process. As a result of this, yabridge plugins can no longer go out of sync as the chainloader will always load the correct version of the yabridge plugin library, even if you didn't rerun yabridgectl sync after an upgrade. In addition, this approach slightly reduces the time it takes to set up plugins, and plugins take up less disk space if you aren't using Btrfs or XFS (in which case yabridgectl uses reflinks instead of copies).

The second user facing change is that VST2 plugins are now set up in ~/.vst/yabridge by default, just like VST3 plugins are set up in ~/.vst3/yabridge. This way you only need to make sure your DAW searches through ~/.vst for VST2 plugins, and it will automatically be able to find all of your yabridge plugins. Be sure to read the bullet under the 'yabridgectl' section in the changelog for more detailed migration instructions, but the short version is that you simply need to make sure that your DAW searches for VST2 plugins in ~/.vst, and that it no longer searches for plugins in any of your Windows plugin directories. After running yabridgectl sync, yabridgectl will inform you about the leftover .so files in your Windows plugin directories from yabridge 3.x. Simply read through that list to make sure there's nothing in there that shouldn't be deleted, and then rerun the command as yabridgectl sync --prune to remove them. If you want to stick with the old way to set up VST2 plugins instead of them being set up in ~/.vst/yabridge, then there is an option available to do so through yabridgectl set.

There are many more noticeable changes, but the most important ones I should mention here are in yabridge's shared memory handling and in yabridgectl's post-installation setup checks. Yabridge uses desktop notifications to inform you about things that are going terribly wrong, and yabridgectl now also checks whether notify-send is installed after running yabridgectl sync. This ensures that you won't miss any important messages. The shared memory handling change relates to how yabridge handles the locking of shared memory. Yabridge uses shared memory to share audio buffers between the native plugin and the Wine plugin host, and it tries to lock that shared memory to main memory to prevent it from being swapped out to the disk. Previously yabridge would simply terminate if it couldn't do so, but now it will fall back to not using memory locking if the user doesn't have permissions to do so. It will, however, still show you an annoying desktop notification until you fix this.

On the backend side, a lot has changed. The biggest change is that the dependency on Boost has been completely removed, and everything has been reworked accordingly. This should make packaging easier, as yabridge now no longer depends on any system library other than the basic libraries needed to interact with X11. Some parts of Boost have been replaced by other headers-only libraries, while other parts now simply use custom implementations. All of this is explained in more detail in the 'Packaging notes' section of the changelog. Yabridgectl also lost its dependency on winedump, at least in most cases. It now tries to parse plugin libraries directly using the goblin binary parsing library. This should also speed up the syncing process. I did, however, run into one plugin that this new parser couldn't handle. If that happens then winedump will still be used instead.

There are many more changes, so I encourage you to read the full changelog below. Oh and on a completely unrelated note, I've been working on a CLAP and VST3 plugin framework and a suite of plugins in Rust, so be sure to check that out as well if you're interested: https://github.com/robbert-vdh/nih-plug

If you need any help setting up yabridge or if you just want to keep up to date with new releases and important Wine related announcements, then feel free to join the Discord.

Added

• Yabridge 4.0 completely revamps the way plugin loading works to allow yabridge to be updated without breaking existing yabridge'd plugins while saving disk space on filesystems that don't support reflinks and speeding up the yabridgectl sync process. Up until this point, yabridgectl sync has always made copies of yabridge's libyabridge-vst2.so or libyabridge-vst3.so plugin libraries for every Windows plugin it sets up. These plugins are tightly coupled to the yabridge plugin host binaries, and updating one but not the other can thus cause issues. With yabridge 4.0, yabridgectl no longer copies the entire plugin libraries. Instead, it now creates copies of these new tiny dependencyless shim libraries. When loaded by a plugin host, these libraries locate the actual plugin libraries on the system and then transparently forward all entry point function calls to them as if the host was loading the yabridge plugin library directly. Yabridge internally calls these libraries chainloaders due to their similarity to the identically named functionality in boot loading process. This allows yabridge to be updated independently of these copied chainloading libraries. As such, it is no longer possible for yabridge to be out of sync after an update. If you use a distro packaged version of yabridge, then that means yabridge can now be updated safely without requiring any action from your side.
• Added support for the effBeginLoadBank and effBeginLoadProgram VST2 opcodes for loading state as a program or a program bank.

Changed

• Almost the entirety of yabridge's backend has been rewritten to get rid of all dependencies on the Boost libraries. As a consequence, the runtime dependency on Boost.Filesystem has also been removed. This makes packaging yabridge for distros easier, and it makes the packages more reliable by removing the need for yabridge to be rebuilt whenever Boost gets updated. Additionally, it also makes compiling slightly faster and the binaries are slightly smaller.
• The functionality for the yabridge-group binaries has been merged into the yabridge-host binaries to reduce duplication.
• When the user does not have the permissions to lock the shared audio buffers into memory, yabridge will now retry mapping the memory without locking it instead of immediately terminating the process. An annoying desktop notification will still be shown every time you load a plugin until you fix this however.
• Yabridge now prints the path to the libyabridge-{vst2,vst3}.so library that's being used on startup. This tells you where the chainloader is loading the library file from. Because you can never have too much information, right?
• The with-bitbridge, with-vst3, and with-winedbg build options have been renamed to bitbridge, vst3, and winedbg.
• effProcessEvents VST2 calls are now filtered out from the log when YABRIDGE_DEBUG_LEVEL is set to 1.

Removed

• Removed the with-static-boost build option since there's no longer a dependency on Boost.Filesystem.
• Removed the yabridge-group binaries as they are now part of the yabridge-host binaries. This saves precious megabytes.

Fixed

• Fixed manually changing channel counts with supported VST3 plugins in REAPER not working.
• Fixed an obscure issue with VST3 plugins crashing in Ardour on Arch/Manjaro because of Ardour's misreported parameter queue lengths.
• Fixed yabridge throwing assertion failures on serialization when using some of the Orchestral Tools Kontakt libraries in the VST2 version of Kontakt. Some of those libraries would output more than 2048 MIDI events in a single buffer.
• Some of yabridge's socket file names contained extremely aesthetically unpleasing trailing underscores. Begone pesky underscores!
• Fixed building with VST3 support disabled.

yabridgectl

• VST2 plugins are now set up in ~/.vst/yabridge by default. This means that you no longer have to add any directory search locations in your DAW. The only potential downside is that it's no longer possible for two plugin directories (perhaps in different Wine prefixes) to provide the same plugin file, although you would not have been able to use both with the same DAW anyways. Like with yabridgectl's VST3 support, the subdirectory structure within the plugin directory is preserved. You can use yabridgectl set --vst2-location=inline to revert back to the old behavior of setting the plugins up right next to the VST2 plugin .dll files. Some migration notes:

  • Because the plugins are now set up in ~/.vst/yabridge by default instead of next to the Windows VST2 plugin .dll file, you will see notices about leftover .so files the first time you run yabridgectl sync after updating. Double check the list to make sure there are no files in there that shouldn't be removed, and then run yabridgectl sync --prune as instructed to remove the old .so files.
  • Make sure your DAW searches for VST2 plugins in ~/.vst.
  • You can and should remove any entries for VST2 plugin directories you added to your DAW's plugin search locations as they will no longer contain any relevant files.
  • If you were using a yabridge.toml configuration file to configure VST2 plugins, then you will now need to move that file in ~/.vst/yabridge instead.

• As mentioned above, yabridgectl now uses the new chainloading libraries when setting up plugins. This means that once you've ran yabridgectl sync after updating to yabridge 4.0, yabridge can now be updated without needing to rerun yabridgectl sync. This is particularly useful when using a distro packaged version of yabridge.

• Added support for the new VST 3.7.5 moduleinfo.json format to allow VST3 plugins to replace VST2 and VST3 plugins with different class IDs.

• Yabridgectl no longer depends on winedump. It now parses Windows PE32(+) binaries without requiring any external dependencies. Or at least, that's the idea. I've come across at least one binary that this new parser can't handle (m4b/goblin#307), so it will still fall back to winedump when that happens.

• After yabridgectl sync has finished setting up plugins, yabridgectl now also checks whether notify-send is installed as part of its post-installation verification process. If notify-send is missing, then yabridge won't be able to send any notifications when things are going terribly wrong.

• yabridgectl status now shows the locations where bridged VST2 and VST3 plugins will be set up.

• yabridgectl sync --prune now also considers broken symlinks.

• The VST3 subdirectory detection has been made more robust and can now handle arbitrary plugin directories, not just directories that are called VST3. This, of course, should not be needed.

• The previously deprecated symlink installation method has been removed from yabridgectl, along with the yabridgectl set --method option. The terminology in yabridgectl status has changed accordingly.

• yabridgectl status now lists the architecture of libyabridge-chainloader-vst2.so just like it already did for the VST3 library.

Packaging notes

• libyabridge-chainloader-vst2.so and libyabridge-chainloader-vst3.so are new files that should be included in the package.
• The yabridge-group binaries no longer exist as they are now part of the yabridge-host binaries.
• The with-bitbridge build option has been renamed to just bitbridge.
• Both runtime and compile time dependencies on the Boost libraries have been removed.
• There's a new dependency on the headers-only ghc::filesystem library to replace Boost.Filesystem. A Meson wrap is included as a fallback for a distro package.
• The headers-only Asio library now replaces Boost.Asio. A Meson wrap is included as a fallback for a distro package.
• Fixed a deprecation warning in the Meson build, causing the minimum supported Meson version to be bumped up to Meson 0.56 from 0.55.
• Yabridge now targets VST3 SDK version 3.7.5 with git tag v3.7.5_build_44-patched.

Compatibility

The archive ending in -ubuntu-18.04.tar.gz is a compatibility release meant for older distros and is thus slightly larger in size. If you're using Ubuntu 18.04, Linux Mint 19, Debian 10, AV Linux MXE 2021, or any other distro that's older than Ubuntu 20.04, then you should use this archive instead of the regular release. If you need a build of yabridge for use with 32-bit plugin hosts, then you can find those on the automated builds page.

Updating

To update from an older installation, simply overwrite your current yabridge and yabridgectl files with the ones downloaded below, and then rerun yabridgectl sync to complete the update.