Comment by wheels
5 years ago
Yes, it is a VST plugin (and standalone), and amusingly probably works better in Wine than Native, aside from the fonts being craptastic. Containerized distribution doesn't really work for plug-ins.
This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement. (I didn't see if that's among its goals, but such would seem reasonable.)
> Yes, it is a VST plugin
Shouldn't that be the easiest way to distribute audio software for linux? It's just a static shared library and maybe some data.
> This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement.
I'm pretty sure they didn't mention pipewire as a replacement for vst or lv2 (or ladspa lol). It's benefit would be for your standalone since it supports alsa, jack and pulseaudio clients and can get decent latency.
> It's just a static shared library [...]
No. First, "static shared library" is self-contradicting: libraries are either shared or static, not both.
The longer answer is that plugins have to be compiled with the `-fPIC` flag to be loadable. The `-fPIC` flag basically says that it has relocatable symbols. You can't link against system-provided static libraries because they're never (by design) compiled with `-fPIC`. It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.
As such, we have to link against shared libraries, and you can have conflicts with the host if it is also pulling in those shared libraries. Ardour, on Linux, specifically, in their own packages, pull in a bunch of non-system shared libraries that conflict with the system ones, which breaks our plugin. There are other shenanigans with other hosts.
> It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.
Sounds like you already know the solution to your problems. Link all your dependencies into your plugin, hide all symbols except the plugin interface and base system ones and you can make your plugin distro-agnostic. If you depend on external shared libraries then yes, your interface to the system becomes a lot more complex and thereby brittle.
1 reply →