Hi everyone
Since we want to use our old Ardour 8 projects—in which we worked with Calf—in Ardour 9, I had the idea today that I could have Claude write a script to convert the presets I export from Calf so that they can be imported into the x42 plugin as accurately as possible. I think he did a great job, and maybe this idea will help someone else who has the same problem make the switch without too much hassle and without having to start the mix from scratch.
Since we use 12 bands, there were two presets where we used x42 in series.
Screenshot (old calf new x42):
Just so you know, Calf’s developer just updated the plugins to use React web UI instead of GTK, so they’ll be compatible with Ardour 9. It looks like he’s updated the DSP too.
Except they now use GTK3 and gtk-webkit
They make the same mistake again, and it’s even worse now.
The plugins will not work with Ardour binaries. They acknowledge this in the ReadMe. Furthermore, the plugin changing the env (LD_LIBRARY_PATH) will also break loading ctrl surfaces in Ardour after loading a calf UI.
Also so far only VST3 plugins. So there is no session compatibility either.
Runtime dependencies
--------------------
The plugin UI renders in the system WebKitGTK webview. If it is not
installed, the plugin window will show a BLACK SCREEN.
Required: WebKitGTK 4.1 (or 4.0), GTK3, ALSA, FreeType.
I have not used calf plugins since perhaps two decades, so I have no direct use for the script, besides I already use the x42-eq.
I’m glad that @MimoMusic not just solved his problem but also shared a solution for others.
I expect a perhaps better match would have been Linux Studio Plugins Project EQ since that offers more bands, and also similar slope configurations matching the calf’s biquad implementation.
Yes, it was more about the process of switching from one plugin to another. Since both plugins are open source, the script tries to match the frequency response. I think that should work with many plugins. While the results won’t be exactly the same, they’ll at least be similar enough that one can continue working with them.
Tone3000 are working fine on my ardour9.8 on ubuntu 26.04. Calf was never working on then (until today). Calf might not be perfect, but my colleague actually liked them. He says it felt natural to work with them. But now we’re switching.
That’s only for Wayland from my understanding of it, and on Ubuntu. X looks to be fine for the most part. I can investigate it and see what happens on Artix (Arch-base).
Once again, it’s purely a Wayland problem, unsolvable if IBM gets their way. It’s incompatible with most software, and the push to adopt it will break things like never before. That’s from my understanding of Wayland compared to XOrg (or XLibre like I use).
I use the LSP plugins as well, but I need to use your plugins more, Robin. I hadn’t used them in a little while, though I have them installed.
EDIT: I figured something out myself, with LLM help of course (on Artix, as I said). You need to make sure, once offline stuff is built from source (including the ui/dist folder is installed where it should be), you disable the WebKit GPU rendering (labeled as WEBKIT_DISABLE_DMABUF_RENDERER=1), and Calf’s GPU rendering if needed (labeled as CALFNXT_WEB_NO_GPU=1). The latter might be required, though the former certainly is.
This graphic toolkits situation is very unfortunate. I get the complexity of the problem, but it’s just such a mess and consequently - such a waste from the user perspective.
Somebody wise and knowledgeable should step in and do for graphic toolkits what Pipewire did for sound (or is trying to do, at least).
This is just an opinion, but it seems to me that there’s no point of putting such an effort in creating floss plugins with these toolkits if the future development is going to render them completely obsolete.
Calf had it’s problems, but i remeber using their limiter and 5 band parametric EQ a number of times in the past and being very pleased.
The graphics toolkit situation has always been actually very simple. On X11 systems, you use an X11 window and you render into it. JUCE has cross-platform toolkits to do this, (as does the VST3 SDK, and even going back to VST2) if you don’t want to create your own. Similarly on Windows it would be an HWND and you render into it. The problem comes when plugin developers insist on using GTK or other inappropriate application UI toolkits (which would also be an issue on other OS). Its an issue of developers choosing the wrong tool for the job.
This isn’t a uniquely Linux problem specifically, but for some reason it seems to be uniquely misunderstood by Linux plug-in ‘developers’. I don’t know if I qualify as ‘wise’ - though I’ve been doing this for a very long time (and I was one of the first developers to make Linux plug-ins with UIs that, worked) - but I’ve given up trying to argue for common sense (most recently around proposed changes to the VST3 Wayland UI extension) because I just get shouted down. So, its a mess unfortunately.
Coincidentally I’ve also noticed a preference for Webview / Webkit UIs (for which effectively read GTK) in the deluge of vibe-coded plug-ins appearing recently too, so I suspect its going to get worse
But…here goes another stupid qustion:
Does that mean that devs could fairly easily correct their mistakes by rendering their GTK-created gui elements in x11 window ( is that possible ) and then “relink” those newly rendered gui elements to the rest of the plugin code (to the functional, non-gui part of it) ?
(if that even makes any sense…as i said, i’m not a dev, i’m only guessing how it all works)
I can’t say what makes sense for other developers specifically. From my own point of view, I developed my own UI toolkit which generally worked for me. The alternative would have been to use JUCE for example. With webviews you do get a lot of things, like accessibility features etc, for free, but as we’ve seen it also comes with a lot of extra baggage that can cause problems too.
(OT - I’m much less involved in all this now because this year has shown me that there is no longer anything creatively, intellectually (or even financially) rewarding for me in spending a year researching, developing, and testing a new plug-in when anyone with an AI can vibe-code something they think is good enough, in a couple days - but that, quite literally is another topic entirely).
Reading about JUCE right now…it makes most sense…it’s libre, it’s C++, it’s cross-platform, it’s widely used, it’s compatible with Ardour. Basically, one needs to rewrite GUI components of plugin and that’s basically it.
There’s no direct way to convert existing GTK GUIs tu JUCE, unfortunately.
This is a great thing, I will try it.
For the moment I use 8.2 for every Project I need to continue wirth calf, but newer Version of Ardour for new projects, where it’s quiet a lot of work to get new plugin settingsas close as possible to my former effect settings with calf.
