SPARTA plugins : impossible to put them in a track

Hi,

I installed SPARTA plugins on Ardour. I see them in the plugin window, but impossible to put them in a track:

github.com/leomccormack/SPARTA/releases/tag/v1.8.0

I did like this:

First, I choose LV2 format, because:

discourse.ardour.org/t/plugin-architecture-best-pick/111088

And, for the location of the .lv2 folders, I read:

lv2plug.in/pages/filesystem-hierarchy-standard.html

So, I put all my .lv2 folders in /lib/lv2/ on my debian 12.11, where I saw a lot of other .lv2 folders.

Plugins appear in Ardour, but impossible to put them in a track.

Can please someone help me?

Thanks :slight_smile:

Any messages in the ardour log? There may also be informative messages if you start ardour from a terminal and look for messages in the terminal after trying to load the plugin.

I see that the plugins are compiled to use dynamically loaded system libraries, which has the possibility of conflicting with Ardour libraries, and there is apparently a library needed which my system does not have (and I would say I have all the common application libraries installed on my system).

$ ldd libcompass_6DoF.so
linux-vdso.so.1 (0x00007f353aef2000)
libsaf_mkl_custom_lp64.so => not found
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f353ae63000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f353ad97000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f353a200000)
libm.so.6 => /lib64/libm.so.6 (0x00007f353a512000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f353ad69000)
libc.so.6 => /lib64/libc.so.6 (0x00007f353a00f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f353aef4000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f3539eb4000)
libz.so.1 => /lib64/libz.so.1 (0x00007f353ad46000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f353a4fd000)
libpng16.so.16 => /lib64/libpng16.so.16 (0x00007f353a4c2000)
libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007f3539d8a000)
libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007f353ad36000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f353a48d000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f3539c35000)
libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007f3539c15000)
libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007f3539bf1000)
libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f3539b46000)

The reference to libsaf appears to refer to this:

The reference to libglib-2.0 is GTK 2, and that is known to cause problems with Ardour.
Plugins should not use heavy weight GUI toolkits such as GTK or QT. If that is actually required it seems likely that these plugins will not work with recent Ardour builds. You might get them to work using a distribution built plugin and distribution built Ardour, but it will always be a brittle setup (and may not work even then, I think Ardour has removed the ability to build with system GTK and only builds with the fork included in the Ardour source tree).

Actually, glib is not intrinsically part of GTK, a plugin may have entirely legitimate reasons to use it, and we have not “vendored” it into our own source tree. It is still a bad idea for a plugin to be dynamically linked to libglib, for the same reason that it is a bad reason for it to be dynamically linked to most libraries. But libglib is not, by itself, a desktop toolkit (it’s more of a portability library, plus a highly evolved event loop).

The libsaf… linkage, however, is entirely and completely wrong. The plugin has been built inappropriately, and should be using static linkage with that library, so that users do not have to have it installed in order to use the plugin.

Thanks,

Good idea, to open Ardour in a termial.

In this case, if I try to put my plugin in a track, this message appears:

lilv_lib_open(): error: Failed to open library /usr/lib/lv2/sparta_binauraliser.lv2/libsparta_binauraliser.so (/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /usr/lib/lv2/sparta_binauraliser.lv2/libsparta_binauraliser.so))

And, on my debian 12.11:

root@k0:~# ldd --version ldd (Debian GLIBC 2.36-9+deb12u10) 2.36 Copyright © 2022 Free Software Foundation, Inc. Ce logiciel est libre; voir les sources pour les conditions de reproduction. AUCUNE garantie n'est donnée; tant pour des raisons COMMERCIALES que pour RÉPONDRE À UN BESOIN PARTICULIER. Écrits par Roland McGrath et Ulrich Drepper.

If I understand correctly, I need simply to have a higher GLIBC version?

At the very least. Did you read the earlier comments about the plugins being linked inappropriately, and how that may cause additional problems?

Notwithstanding the other issues mentioned above, there have been a couple of topics on Linux Musicians forums with the same issue - plugins requiring GLIBC later than what is provided in Debian 12. Notably Kazrog plugins - Kazrog plugins are coming on Linux - LinuxMusicians which is well worth reading, and recently DDMF plugins, both of which are recently ported to Linux and require GLIBC ≥ 2.38.
If you don’t want to read, the discussion centres around the fact that most plugins don’t need the latest shiny GLIBC and it would be advantageous to compile with an older version to ensure more broad compatibility.

Thank you,

And it seems that the new Debian 13 Trixie has glibc version 2.41 (trixie-glibc) and one day, I will have to upgrade my OS version.

It does indeed. There is another collection of (commercial) plugins by ToneBoosters I tried several demos of which work in Trixie but not Bookworm. Some very nice plugins in these and the other 2 I mentioned above, but my budget doesn’t extend very far for buying plugins.

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