2 vst3 plugins not registering in Ardour

Ubuntu-Studio 22.04
Ardour 8.12.0
Jack
Carla

I’m beta testing a Linux version of a vst3 plugin called fase
https://opinionatedchaos.com/fase

problem: fase vst3 shows up Ardour’s plugin-manager flagged w/ “error”, and won’t load, but is recognized by Jack/Carla…meaning, I can instantiate the fase vst3 in Carla then route to & from Ardour there but can’t load the plugin into a channel strip.

I also have a similar problem with the Curvature compression plugin
https://apmastering.com/plugins/curvature
but this Linux vst3 it isn't recognized by Ardour plugin manager at all, doesn't show at all 
//I didn't have time to test instantiating it in Jack/Carla and routing there but will try this later

- are there issues w/ loading more recently built Linux vst3 plugins in Ardour 8.x.x?
- i.e. is there a vst3 compiler issue, a kernel issue, UI lib issue?  

thanks in advance!

The most common problems with plugins are that they use a complex GUI toolkit such as GTK which conflicts with Ardour GUI routines, or is compiled using dynamic libraries, and one of the dynamically loaded libraries conflicts with an Ardour library.
Plugins should be self contained, linked statically against any libraries that they need, and should not use heavy weight GUI toolkits such as QT or GTK.

Start with checking those things (you can often find out without waiting for the developer by using the tool ldd to display the dependencies of the plugin binary).

1 Like

output from ldd on the fase plugin below
any conflicts with the Ardour lib?

/usr/lib/vst3/fase.vst3$ ldd /usr/lib/vst3/fase.vst3/Contents/x86_64-linux/fase.so
linux-vdso.so.1 (0x00007fff91a6b000)
libasound.so.2 => /lib/x86_64-linux-gnu/libasound.so.2 (0x00007f98cf850000)
libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f98cf806000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f98cf73e000)
libatomic.so.1 => /lib/x86_64-linux-gnu/libatomic.so.1 (0x00007f98cf734000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f98cf508000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f98cf41f000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f98cf3ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f98cf1d6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f98cffb3000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f98cf1a5000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f98cf19c000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f98cf161000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f98cf145000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f98cf135000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f98cf112000)

yes, a plugin should be statically linked and not depend any system wide libs (save for libc, libstdc++), similar to plugins on Windows or macOS.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.