This is doing my head in…
Rack Pro 2.1.2, Bitwig 4.4.3 and Ubuntu Studio 22.04
When I first got Rack Pro (using Ubuntu Studio 20.04) and tried to open the vst in Bitwig it failed with this message
com.bitwig.flt.library.metadata.reader.exception.CouldNotReadMetadataException: could not read metadata: createAEffectInstance returned NULL
but I fixed it by moving the Rack .so files to a sub-folder below ~/.vst
Ubuntu 20.04 has come to the end of its life, so I installed 22.04.
The same error has returned but moving the .so files doesn’t work. I’ve tried everything I can think of, moving files, starting with complete new installations of Bitwig, Rack and Ubuntu, no change.
Has anyone got any ideas? I don’t really know if this a Rack problem or Bitwig? Other vsts2 .so (e.g. u-he) files work fine.
I was going to reply effectively the same, wondering how 20.04 “has come to the end of its life”, as it’s an LTS release with long standard and extended support? Not a Ubuntu user here, so I was honestly perplexed reading this.
Rack 2 hasn’t worked in Bitwig on Arch for me for nearly a year now. If the same problem has made its way into Ubuntu I wonder if it will finally be fixed.
OK, End of Life was a poor choice of words but 20.04 has been superseded by 22.04 LTS. I also have other problems with 20.04 (e.g. I can’t install the Blamsoft modules, but they work on 22.04).
Anyway, I’m still trying to understand what has changed, and how I can fix it.
Could not process audio on client audio thread 2 using remote audio thread 0: End of stream
Could not compute parameter text from normalized value: Plugin host died: Could not process audio on client audio thread 2 using remote audio thread 0: End of stream
Killing pluginhost process
Waiting for plugin host process to exit
Could not read async reply: End of stream
Plugin host process exited with code: 139
You’re not using the flatpak version of Bitwig are you?
I don’t understand this issue, but it always comes up. For someone who does understand - why is this always a problem with Linux? I there something wrong with the build process for VCV and modules? Or does VCV some how dynamically link to libraries and pick up the wrong one from Bitwig? Or is it just “impossible” to distribute pre-built software for Linux?
I don’t think it’s impossible, this used to work for me until I upgraded Linux. When I have some time I’m going to re-install the old Linux, VCV and Bitwig on a bootable drive just to prove this to myself!
I’m not a programmer but it seems to me that there is a difference between VCV and other vsts which work in Bitwig with no problem. For other vsts the .so file is the entire plugin, though there may be presets, graphical resources etc in separate folders below the main folder holding the .so file. For VCV this isn’t the case, as I understand it. The .so file in ~/.vst links to the main program files in /usr/share/VCV and and modules and saved patches in ~/.Rack. Bitwig also has external dependencies, I don’t know if this is the case with VCV. It’s this complexity which, IMO, might be behind the problem.
VCV Rack has its own libzstd, for which all symbols need to be visible as it is part of the whole Rack SDK.
Issue is that system library libzstd is required for new mesa (opensource GL drivers), and this version is not ABI/API compatible with the one provided by Rack.
When GL operations take place on some linux systems, the userspace side of the graphics driver will call some libzstd functions. Typically the system lib would be used, but since Rack has its own built-in libzstd, the built-in version is used instead. Unless both built-in and system versions are made to match, we can expect issues.
To put it in example generic terms:
let’s say a host uses libfoo.so.2 while a plugin uses libfoo.so.1, where internal ABI details changed from v1 to v2.
When this host loads the plugin that uses old libfoo.so.1, plugin actually will call libfoo.so.2 stuff.
This becomes undefined behaviour, and crashes are not unexpected.
Rack is the plugin in this example.
I see a few possible solutions:
update libzstd to latest (bad one, will get into the same issue later on again)
run the whole Rack out of process, so host vs plugin symbols no longer clash (has performance impact)
place all libzstd calls under its own custom namespace (requires new Rack release and rebuilding all plugins)
Thank you @falkTX for that very complete answer, I think I get it. So if I could revert my Linux system to the same version of libzstd as VCV uses it should fix the problem, is that right? Although this may cause problems for other parts of the wider system that depend on newer versions of the library?
Do you (anyone?) know what version of libzstd would be compatible with VCV?
But that is not a realistic solution… at some point when everyone updates (and not just archlinux with latest mesa), Rack will be broken in any recent linux distro for you and many others.
Thanks again @falkTX at least I understand the problem now. I’m thinking of making a separate system for music work, either dual boot or another drive, with an old Linux that I don’t update. Inconvenient though.
Please do. VCV are aware of this issue but it seems to not have a great importance to them so if this problem has made its way into such a mainstream distro as Ubuntu then they really need to know and to do something about it. We shouldn’t have to use an old distro or dual boot to use a product on a platform they apparently support.
Sounds like the right solution to me and I’m surprised that all bundled libraries in Rack are not called this way right from the start, as it’s a know recipe for problems, or at the very least when Rack Pro was created. One question I’m not clear on: Since Rack code is C++ it can use namespacing. C code doesn’t have namespaces. Will namespacing it’s usage in the C++ application (Rack) still work to isolate it’s symbols or will they just leak out globally because it’s C code?
Adding some data to this. I am running Ubuntu Studio 22.04, Bitwig 4.4.3, and VCV Rack Pro 2.0.6. Everything is working fine, no errors. So, it is possible to get it to run properly with that setup. Unfortunately I am not knowledgeable enough to help fix the errors mentioned here, but maybe it is helpful to know it can be fixed maybe?
v2.0.6 is 9 months and 3 releases old now, so it’s not certain that your datapoint applies much. IMHO everyone should really be running v2.1.2 at this point.