Calf plugins -- library issue

#1

I’m using Ardour 8.6 (downloaded binaries). I recently upgraded from Fedora 37 to 40 (one release at a time, but back to back). After this, Ardour claims that it can’t find my Calf plugins (it shows the “Missing Plugins” modal window). Other plugins are fine; it’s only the Calf stuff that’s affected. I’ve come up with a workaround, but wanted to document the issue and hopefully find a less janky fix.

The in-app log shows:

2024-05-06T11:27:10 [ERROR]: LV2: Failed to instantiate plugin http://calf.sourceforge.net/plugins/Compressor
2024-05-06T11:27:10 [ERROR]: Found a reference to a plugin ("http://calf.sourceforge.net/plugins/Compressor") that is unknown.
Perhaps it was removed or moved since it was last used.

…and so on for each Calf instance.

strace shows that it is in fact enumerating the plugins and attempting to load them.

When run from the command line, the relevant error message is:

lilv_lib_open(): error: Failed to open library /usr/lib64/lv2/calf.lv2/calf.so (/lib64/libinstpatch-1.0.so.2: undefined symbol: g_once_init_leave_pointer)

…again, once for each Calf instance.

Calf version:

$ dnf list installed | grep -i calf
calf.x86_64                                      0.90.3-18.fc40                                  @fedora                
lv2-calf-plugins.x86_64                          0.90.3-18.fc40                                  @fedora                
lv2-calf-plugins-gui.x86_64                      0.90.3-18.fc40                                  @fedora

From dnf logs, it looks like the old version was 0.90.3-12.fc37. Downgrading to this version did not help.

As suggested above, calf.so depends on libinstpatch:

$ ldd /usr/lib64/calf/calf.so 
	linux-vdso.so.1 (0x00007ffe159ea000)
	libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f3b55dbd000)
	// etc...
	libinstpatch-1.0.so.2 => /lib64/libinstpatch-1.0.so.2 (0x00007f3b5480a000)
	// etc...

libinstpatch has a reference to g_once_init_leave_pointer:

$ nm -D /lib64/libinstpatch-1.0.so.2 | grep g_once_init_leave_pointer
	U g_once_init_leave_pointer

…which is defined in the system libglib-2.0.so.0:

$ nm -D /lib64/libglib-2.0.so.0 | (grep g_once_init_leave_pointer || echo nada)
0000000000088d90 T g_once_init_leave_pointer

…but not in the one that ships with Ardour:

$ nm -D /opt/Ardour-8.6.0/lib/libglib-2.0.so.0 | (grep g_once_init_leave_pointer || echo nada)
nada

If I invoke Ardour with “LD_PRELOAD=/usr/lib64/libglib-2.0.so Ardour8”, it loads the plugins okay, but double-clicking on the plugin in the mixer window does nothing in the GUI, and produces similar results in the in-app log:

[ERROR]: failed to instantiate LV2 GUI

…and on the terminal:

suil error: Unable to open UI library /usr/lib64/lv2/calf.lv2/calflv2gui.so (/lib64/libgdk_pixbuf-2.0.so.0: undefined symbol: g_task_set_static_name)

Adding /usr/lib64/libgio-2.0.so to the pre-load led to:

/opt/Ardour-8.6.0/bin/ardour-8.6.0: /opt/Ardour-8.6.0/lib/libmount.so.1: version `MOUNT_2_40' not found (required by /usr/lib64/libgio-2.0.so)

Adding /usr/lib64/libmount.so produced:

/opt/Ardour-8.6.0/bin/ardour-8.6.0: symbol lookup error: /usr/lib64/libgio-2.0.so: undefined symbol: g_module_open_full

Finally I got things “working” with LD_PRELOAD="/usr/lib64/libglib-2.0.so /usr/lib64/libgio-2.0.so /usr/lib64/libmount.so /usr/lib64/libgmodule-2.0.so" Ardour8.

This seems to work in basic testing (the track plays, the compressors compress, the GUIs gui, etc.), but obviously I’m not super comfortable running it this way. Any thoughts on a proper fix?

#2

Put more simply, the version of CALF that you have has been built against a “too-new” version of glib.

#3

A proper fix would involve Calf plugins not linking GTK libraries. Plugins should be self contained without using any shared libraries which may or may not conflict with the plugin host.

#4

Yeah, that too. And two more toos, to, to get to 20 characters.

#5

Thanks for the fast reply. Your summary makes sense, but it’s strange that downgrading to the earlier release of Calf didn’t solve the problem. I’ll try it again just in case I did something dumb.

Assuming that doesn’t work, do you have any other suggestions, or perhaps some reassurance that my workaround is safe (where “safe” >= “won’t corrupt my projects”)?

#6

Thanks for the reply, and yeah, I encountered a very similar comment (from you perhaps?) while troubleshooting this. I’m not terribly heavily invested in Calf, so if this something that’s likely to recur, perhaps the real solution is simply to migrate to something else. At least with the workaround I can easily copy my settings to other plugins.

In your experience, do other plugin authors tend to get this right?

#7

It has varied, but recently most get this right. The OverTone/ACMT plugins have always gotten that right, and of course the plugins where Robin “x42” are involved get it right, such as ACE and x42 plugins. I believe the Linux Studio Plugins have a self-contained GUI toolkit as well so that they do not link to any system GUI libraries (they do since the 1.1.0 release at the end of 2017,so only very old LSP have a problem).

1 Like
#8

see also

#9

I think, Calf is still popular :smile:

#10

which is insane.

Given that amount of issues those plugins have, nobody with at least one good ear would use those plugins unless they want to add distortion [1] (using calf’s EQ (!)), phase smearing [2,3] (using any calf multi-band effect), or zipper noise[1,3] (automating any calf plugin), just to mention a few things…

There’s nothing wrong to use the plugins for, say, special effects; but they’re pretty much useless for a clean mix or when mastering.

If you learn[ed] to mix with calf, you’ll likely have a hard time to use professional tools later.

–

[1] Decrease db with automation for a lowshelf - #2 by x42
[2] How to achieve multiband processing? - #16 by x42
[3] crossover filter bank don't have a flat frequency response · Issue #217 · calf-studio-gear/calf · GitHub

3 Likes
#11

Just my 2¢: I learnt the rudiments of mixing using mainly Calf plugins (before I knew about their weaknesses). These days I mainly use LSP, Airwindows and your own x42 families of plugins, but the basics of what each type of plugin doesn’t change, and I still believe that the UI in the Calf family is very well designed, very intuitive. I believe that the operational principles I learnt with Calf eased my life when I moved to other plugins.

#12

I don’t use Calf plugins, but I do enjoy tinkering with open source software. I had been wondering for a while if “XUiDesigner” by @brummer could produce GUIs for Calf plugins in place of the GTK ones that no longer load in Ardour’s official versions. As proof of concept, I created one using the default setup and just moved a few knobs so the text wasn’t cut off. It loaded in Ardour 8.6 just fine. I was thinking it would be fun to recreate the original GUI as closely as possible, but I am not sure when I would have time to do it or how to share the results. In the meantime, though, I wanted to let those that rely on Calf plugins know that making your own GUIs is an option. It only took me a few minutes to make this one (Vintage Delay), and I have no programming skills. Kudos to @brummer for making such a cool program and sharing it with the world.

image
image1359×695 114 KB