Have you in plan change gui from gtk to other like juice or something cross-platform?

[proboofficial]

New version of Ardour 8.4 dont want work with calf plugins. Problem is too old gtk version

[darinrogers]

For those searching, I believe the error you'll see is "[ERROR]: failed to instantiate LV2 GUI".

[proboofficial]

Yes is this error, but I think good idea is make calf studio gear cross platform tool

[bratpeki]

Either:

• using a new GUI framework (Qt, GTK+, GL/Vuklan,...),
• reverting to a generic LADSPA interface or
• using a new plugin framework altogether (stuff like DPF and JUCE).

[bratpeki]

In the meantime, the Debian Multimedia Maintainers are hosting calf-ladspa, which is GUI-less, but functional [citation needed].

[trebmuh]

See also: https://github.com/calf-studio-gear/CTK

[boomshop]

Those problems were already in sight a couple of years ago, that's why I started CTK - as a replacement for GTK2. Basic stuff already works afair, things like composing, layering, event bubbling, clipped region redraw and the like. Still a long way to go. After CTK is done, Calf needs to adapt to the new toolkit. Since it has grown into this huge pile of "devices" and still suffers from a few design flaws UI-wise (e.g. direct access between UI and DSP needed) it's nothing to be done on a Sunday evening but more like an effort of several man months.

Another approach I had in mind was using a webview in combination with our web widget library AUX Widgets to speed things up. But. I unfortunately don't have time - neither for Calf nor for CTK - anymore, so I fear this is the nail in the coffin as of yet.

Bummer, since it's still the only plug-ins I'm using in my studio.

[falkTX]

I have a proposal that can buy us a few more years time - starting the gtk UI out of process and doing X11 window reparenting.
The idea being that the lv2 ui object would be a fake one that starts an external process with the real gtk UI, and use IPC to send any received data to it and vice-versa.
We can use LV2 X11 UI type to show the UI as embedded, giving a similar feeling to before, but without conflicts of e.g. host using gtk3 or a modified gtk2 like ardour.

This would allow to load the calf UI, assuming the linux distro still ships with gtk2 of course.
It is not hard to do and gives quick results

The main problem here is calf plugin graphs being tied to their DSP side, if we start the UI in an external process we lose access to them.
If that is an acceptable trade-off, I can come up with something quite quick to allow to load the current UIs

[falkTX]

@boomshop I was going to reply to your email, but I was too curious to see if my ideas could work well enough so I ended up creating https://github.com/falkTX/lv2-gtk-ui-bridge in the last 2 days 🎉

This allows us to use lv2 gtk2 uis on any host that supports x11 ui type.
Verified to work on latest Ardour with Calf, EQ10Q stuff and Invada.
Also works for loading gtk2 uis in jalv.gtk3 😅
Does not work in Reaper though, because it does not seem to support "out of main bundle UI" kinda deal that I setup on that repo. But that is mostly a technicality, if we define the UI inside the calf.lv2 bundle it will load the UI

Initially I thought about something that would be useful just for Calf project, but ended up with a generic approach, so that is why it also works for EQ10Q and Invada.
Can easily add support for more, this uses a hardcoded list of plugin URIs to give the extra X11 UI to.

Anyway, testing and feedback is appreciated and all that.
Quite minimal deps, so should be easy enough to build.

PS: A side effect from this is that we can reuse it for more esoteric usecases too, say gtk3-webkit to have a web view as plugin UI. the process separation means we can use whatever libs we want without worry, and that includes any gtk or web view version

[boomshop]

@falkTX just wow. That's genius! Will test it and report back any problems once I find the time.

if we define the UI inside the calf.lv2 bundle it will load the UI

Are there any implications to this in your opinion? Other than having lv2-gtk-ui-bridge as a dependency. E.g. breaking the homebrew version for MacOS, not having the bridge packaged for the various OS yet, something along those lines. We could also offer a set of manifests for Reaper users, or a script manipulating them.

Thank you so much dude!

[falkTX]

if we define the UI inside the calf.lv2 bundle it will load the UI

Are there any implications to this in your opinion? Other than having lv2-gtk-ui-bridge as a dependency. E.g. breaking the homebrew version for MacOS, not having the bridge packaged for the various OS yet, something along those lines. We could also offer a set of manifests for Reaper users, or a script manipulating them.

I think the best course of action is to eventually have this special bundle be part of calf, I think that makes the most sense on the "long"-term.
I still need to finalize the windows part of the IPC stack, it is something I had a few issues before. macOS and Linux/POSIX already works though.
So as I see it, we let this be a separate project for just a bit to do quick experiments with, and once stable we can move things into the calf project

[falkTX]

@boomshop were you able to try it? I finalized the windows IPC parts though for this gtk2-external-in-x11 thing is not that useful since it relies on x11 embedding.

if we would be integrating it into calf I need some help as my knowledge of autoconf/autotools is very lacking.
very roughly the steps would be:

1. add the project source files in this repo
2. set autotools to build those files if detecting x11 linux/bsd system (and lv2 gui is on)
3. set the build so that it creates 2 new objects: 1 shared library for the x11 gui, one executable for the gui wrapper
4. tweak the lv2 ttl generator to add the x11 gui details
5. tweak the copied ipc code to minimize to calf needs (the C files, for no gtk3 or lilv needed)

I cannot do the step 2 and 3, but can do the others

[boomshop]

@falkTX sorry, I'm totally drowning in work atm (we have a huge contest for smoke divers upcoming where I'm the only developer voluntarily building the software to handle the whole contest) so I didn't have time for literally anything unfortunately. Let's see... @kfoltman are you still around - maybe able to give a helping hand? Would be ace!

[falkTX]

@boomshop no worries, I might go ahead and do a first beta release for the lv2 bridge project then.

[x42]

Keep in mind that calf is still on the list of packages to be removed with the next debian release (when gtk2 is dropped):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713

[falkTX]

Keep in mind that calf is still on the list of packages to be removed with the next debian release (when gtk2 is dropped):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713

sounds like a good reason to release it now before it becomes completely worthless.

is gtk3 going the same path too?

[JohannesLorenz]

@falkTX I currently planned a CALF bugfix release 0.90.4 in the next months. Should the gtk change be included or separate?

Also, FYI, on branch "github-actions", I set up CMake for CALF which already works. If that helps you with anything, feel free to use my CMakeLists instead of automake.

[falkTX]

@falkTX I currently planned a CALF bugfix release 0.90.4 in the next months. Should the gtk change be included or separate?

feels too much of a change to include in one go, specially since a release has not been made in a long time.

the cmake side for sure helps to setup the build to have this extra x11 embed option. are you wishing to proceed with cmake for real or just testing the waters here?

[x42]

is gtk3 going the same path too?

Yeah, you'll have a few more years. Then again https://github.com/lv2/lv2/wiki#avoid-gui-frameworks

If this project is to continue, calf should first get its act together and fix the countless DSP issues. That's my 2c.

[suedwestlicht]

Well, as a non-programmer and user of Calf plugins my biggest worry are not some DSP bugs, but the impending inability to use them due to UI-toolkit issues.

They are easy to use, beautiful and sound good - even if, for example, the filters of the multiband plug-ins change the sound or the transient designer pops after signal pauses (a very quiet signal immediately before the "real" signal provides a remedy here).

[JohannesLorenz]

@falkTX I currently planned a CALF bugfix release 0.90.4 in the next months. Should the gtk change be included or separate?

feels too much of a change to include in one go, specially since a release has not been made in a long time.

OK, in this time I would just ask you to park your changes in a PR before moving to master, until we have 0.90.4 released.

the cmake side for sure helps to setup the build to have this extra x11 embed option. are you wishing to proceed with cmake for real or just testing the waters here?

For real. On the github-actions branch, both are already equally good. I think CMake should soon be the prior build system, and, as for me, automake should be removed in the near future (to avoid making all changes in 2 build systems).

[ghost]

an additional perspective: the signal processing issues make sense to me, that seems like a good reason to move away from CALF. However, I don't have a time machine, and I already have many project files that do use CALF, often for synths and as part of non-trivial filter chains that can't be perfectly reproduced. I start things, run out of steam, sit on them for sometimes years, and come back to them, so backwards compatibility is pretty important to me!

I'm not a C++ developer and am not very familiar with the details of linking and stuff, is there not a way to just statically link the GTK2 dependency and prevent exporting any of GTK's symbols to avoid clashes? I wouldn't mind the wasted memory in exchange for not losing many hours of work

[tl072]

I don't have a time machine, and I already have many project files that do use CALF, often for synths and as part of non-trivial filter chains that can't be perfectly reproduced. I start things, run out of steam, sit on them for sometimes years, and come back to them, so backwards compatibility is pretty important to me!

This is really the core of the issue I think. I am in the same boat. I cannot insist that people do coding for something that I am not sure I am even capable of doing (without a lot of new learning for a becoming obsolete framework), but hopefully my experience and @your-friend-alice are inspiring enough to keep things moving :) The DSP questions probably have merit given the knowledge of the people I have seen making reference to them, but for what it is worth, I have really enjoyed using the calf plugins and i think they sound good for whatever it is that I do :)