I’m evaluation Ardour and I run it on a Ubuntu 26.04 PC. Ubuntu comes with Ardour 9.0, but I wanted to try Ardour 9.8. Unfortunately, I got problems with one of my plugins, liquidsfz. I’m using liquidsfz to run a sfz version of Naked Drums (quite good sounding drums btw).
liquidsfz uses the systems kdialog, yad or zenity to choose the sfz-config-file. Unfortunately, there seems a lib conflict with Ardour 9.8. Ardour 9.0, which comes with Ubuntu 26.04, runs fine.
All three file chooser (kdialog, yad or zenity) don’t work. E.g. Yad gives the following error:
I think maybe there is a problem with some libs Ardour 9.8 comes with. Does the startup code of Ardour 9.8 manipulate the LIBRARY PATH and the plugins (eg liquidsfz) load the wrong library? Could this be fixed?
Workaround: I wrote a simple filechooser with FLTK and patched liquidsfz to use that filechooser.
Is this the exact version you are using? If not, what happens if you use this version? I am presuming it is properly statically compiled at least based off their description (Really ALL plugins should be self-contained and not use system libraries for UI).
No, this is not the version I am using. The plugin itself is running fine. But for selecting the filename of the sfz config file, it launches a host application (kselect, yad, zenity). Those applications won’t run, launched through Ardour9.8. If I type yad --file in a shell, it will start and one can select a file name. As said, I found a workaround. I simply wrote a fileselector with FLTK which is self contained. I compiled liquidsfz myself and patched it to call my fileselector programm instead of kselect, yad or zenity.
Maybe this is related to the way Ardour modifies the environment before it starts the main binary? I had problems trying to launch a browser from within a plug-in (typically when the user clicks a ‘buy online’ link in a license pop-up). This turned out to be the way ardour modifies the LD_LIBRARY_PATH to prefer its own versions of some system libs e.g.
# Set this so that the executable will find all the right libraries inside the bundle
export LD_LIBRARY_PATH=$INSTALL_DIR/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
(The browser would load the wrong libraries and freak out about security, which is - technically - the correct response)
My workaround / fix was to preserve (Ardour’s) environment, null out the LIBRARY_PATH and then restore the (Ardour’s) environment when done.
A common problem. The solution is to make sure that plugins are self contained and do not rely on any system libraries.
Unfortunately there isn’t one simple cure-all. There is a persistent myth that plug-ins should be completely self-contained, but that is rarely practically possible, especially for complex plug-ins (and may also not be possible because of licensing), instead one has to accept some (but minimal) dependencies (in fact it may be essential to depend on some shared system libraries as a matter of ensuring compatibility. In this respect the problem actually might be exacerbated if Ardour uses / prefers, its own modified or specific versions of standard libraries inside its application bundle)