Hi,
I’m fully bathing in Enlightened skeumorphism these days, Flat is OK too… There used to be a time when people enjoyed variety and difference, both can be beautiful when composed decently…
But more importantly are they back with non-GTK X11 UI’s or some meaningful change underneath? I simply avoided the bad ones and enjoyed the good ones, it’s a large set, again how about some nuance…?
I guess it’s because they ship older Ardour 8.4. instead of newer version available in debian. Back then it was still possible to use system-wide gtk2 (same as calf).
Understood, so not really ‘back’ at all… They never left if you use falkTX’s life-support hack, I continue to supply them (and the hack) in AVL for User continuity for a while longer anyway… Without a toolkit change they are indeed on life-support…
Yeah, it’s a not great that it breaks old sessions once those plugins are no longer available.
Then again we’ve been telling users to avoid calf since 2012,…
It’s mad how important this is to some people…! And there’s me wishing I could open every plugin by default using Ardour’s generic UI (I think this option was removed some years ago).
Side note - I once did my own wee shootout of master bus compressors / limiters just for myself out of curiosity and, after switching off plugin UIs and using Reaper’s own, found that the best results (to my ears) came from Airwindows’ Logical4 / ButterComp and ACM70SA and x42 Peak Limiter, ahead of more expensive options like Presswerk.
Over a decade ago I tried Calf plugins but was never impressed, can’t remember why though. In any case, at the risk of sounding a bit insulting, I imagine people would favour other plugins (LSP suite, x42, etc) over the Calf ones if the Calf GUIs were not as polished nor unified nor skeumorphic. But I may just be being ignorant there…?
Fwiw: I recently discovered that the free version of at least one commercial plugin had the restricted knobs exposed in Ardour’s generic GUI.
It has never been removed, and is available from the context menu of the processor and also by Alt+double-click, see tooltip:
However, plugins that combine DSP and GUI in the same shared-object (.so, .dll, .dylib) or rely on external system-wide libraries (like calf does), will fail to load regardless.
Thanks Robin 
I was referring to this initially but you’re absolutely right, Alt + double-click is perfectly fine.
I need to pay more attention to the tooltips I think…!
Sounds like they put a lot of work into all the wrong places, and maybe it’s why Calf is so abysmal! They need to revamp the underlying tech and bring it out of the early 2000’s, and reevaluate their reasoning behind their actions, because it’s been bad for far too long to see its developers as taking its development seriously!
I totally understand that making FOSS is not easy and have a life and sufficient income too, but without showing a good reason why good developers would want to join the project and get busy, and give users a reason to support it, it may never come back in all reality. And many a project has perished for those and similar reasons.
I have never read any input to this forum, nor the more general Linux audio forums by anyone of the Calf project, not that they may not be in here somewhere, but I have yet to see them ask for suggestions and peoples opinions, discussing the project, it’s progress…
Maybe that’s just me, so correct me if I’m wrong, but if I am not too far off, than it’s not a good sign and doesn’t encourage me to use their plugins.
Meanwhile Robin lives here and X42 is pretty darned good!!!
Aren’t these the plugins everyone says is shit? 
Yes, but there’s a lot of old projects using them.
I would say they shouldn’t be used for new projects, but if you have an old project which used CALF plugins, you probably don’t want to re-work it if you were happy with the results you got
Cheers,
Keith
I’m not going to advocate for Calf’s DSP, the folks in the know here have identified some major DSP deficits but it seems we have a bit of a post-game ‘pile-on’ here with what are probably more opinions than facts…
Can we please take some important historical facts into consideration? When I started with Linux Audio at the infancy of Ardour 2.0 there were LADSPA Plugins with no GUI at all… For those (like me) coming from a Windows production background this was insanely archaic. When LV2 arrived as a LADSPA successor there was Invada and Calf providing the first UI’s, there was also linuxDSP actually creating early Plugins with UI’s but at the time they were JACK-only and only later became LV2 after this. There were no proper UI’s previous to this in a Linux-only Plugin format and there was no convention in a mountain lair somewhere to advise and decide how to best handle Plugin UI’s so Calf and Invada used GTK and Linux Audio production then had both an improving DAW and some Plugins that didn’t look like they were from Windows 3.1. So maybe the Calf developers weren’t DSP experts and maybe starting with GTK was doomed (linuxDSP was X11 from the outset) but some generous people took a LOT of spare time and a LOT of effort to create something with the best of their knowledge at the time that hadn’t been done before. Maybe stop shitting all over their work all the time folks and maybe tip your hat and say “hey, thanks for being pioneers!” and from there use your ears to listen and eyes to read and to evaluate what works and doesn’t work for you. These guys aren’t perfect and for whatever reasons their development efforts slowed and stopped… so would mine if I had to read such harsh ingratitude every day. Their work is an important chapter in the story of Linux Audio. In FOSS, projects ARE people so maybe before being vocally critical think about whether you’d say this to a person and not a product…
Completely agree to what @GMaq said!
Their necessity in 2025 however should be questioned. If you have to rely on them for old projects … welcome to production life and no, that’s not a linux only issue. There are several very good for the time plugins that only live as 32bit VST2 and bridging them is not always successful. F.e. my good old Focusrite LiquidMix is pretty much useless sadly. (Depending on firewire doesn’t help either.)
That’s why always consolidate your tracks to have your processing at the time archived.
I agree in what should be applauded but the situation stands today where their plugins are faulty in the sonic department as well as increasingly a problem with the GTK toolkit and there is no indication they will fix them. Which is fine except they still keep advertising them, rather than directing people to newer, better maintained alternatives. They are also now releasing new versions which are just maintenance mode by the looks of it.
All, whilst there are endless posts asking for support about them. CALF gui don’t work threads are likely the second most common types of threads after “My $300 windows vst doesn’t work on linux. Can you ,who didn’t get the $300, fix it for me”.
Actually they did something to address the GTK problem:
Yes, this is kind of workaround but still…
Applause for that stance.
As we all know, the history was written by those who survive. So, what I miss all times in those discussions was the point that DAW’s clime for themself to use GUI toolkits like GTK or QT, but force plugin developers to wrote there owns. Just count it down, how may DAW’s do you use with how many plugins? So the situation we are now have is that 100drets of LV2 plugin developers wrote there own toolkits instead develop dsp related stuff. Just, because 3 or 4 DAW developer say “This toolkit is mine”.
That means, if a DAW use there own toolkit, there is no issue at all with plugins using GTK or Qt, or “You Name It”. At least, Reaper does that, … does that, . . . . .
The issue with GTK and Qt is not that the host uses it.
It’s that different versions of GTK cannot exist in the same address space. The same for Qt.
So, any combination of plugins or hosts that use different versions of GTK or Qt will cause issues. It might be a plugin and the host, or two different plugins.
It’s also unclear why anyone would naturally gravitate towards GTK or Qt, which are clearly GUI toolkits that provide a central event loop for the application, when writing a plugin that is meant to be a statically linked, standalone shared object. They are also toolkits that provide almost no widgets useful to most plugin GUI authors.
Just checkout the “Programing with LV2 book”, the first GUI example you’ll find is still, . . . gtk based.
https://lv2plug.in/book/#_sampler_ui_c
and it was this way thins ever.
In Linux, were either distributions take care about the used toolkit version, or, when the user compile by itself, there wont be any issues introduced by toolkit versions.
To make that clear, the issue with calf in ardour is clearly introduced by ardour using a special gtk version which no distribution nor a user would be able to use, so no way to build Calf against the same GTK version. And now, when Ardour using GTK implemented as a fixed include own toolkit witch use symbols from toolkits which are usually free available, without allow to build against a official version of this toolkit, well, as I said in my first post, the winner takes it all and wrote the history.
Please, don’t take my words personal, it’s just that I was bitten by the same snake. I’ve done my own toolkit for my plugs, and now wayland comes around. Would I start again the same jumble? No, I wouldn’t.
In the context of “Linux distributions”, they have all (? most already, all soon) dropped GTK2 entirely …
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.