CALF plugins?

[funkmuscle]

Okay I'm a little bit lost here. LSP and airwindows You take the exact approach. You move the slider to hear what happens You turn a knob to hear what happens.

In fact I needed a flanger for a guitar track and I figured that's try LSP. Didn't have a clue and I just started to turn knobs and I got what I wanted. What's the difference to turning knobs compared to moving a slider? Yes LSP looks complicated but once you start turning the knobs you figure out what stuff would do.

[Linuxmusician01]

[...]
Airwindows plugins, are at the opposite extreme, they do very little, but they do it very well (maybe a few more aids for setting parameters would help).
[...]

Thanks for the "tip": mistakenly I always assumed they were for Windows. The Help file (a text file in the Zip) may not be the best help but the developer has a ton of video's on Yuotube: that helps.

However, they come over as a bit, ..., "specialized"? That is, I miss a simple phaser and flanger (maybe I'm not searching good enough...) or a Leslie Rotating Speaker. The LSP daoesn't have a phaser either... Calf has 'm though.

[Largos]

As well as LSP, there are also Invada, Zam, x42, TAP (which some of the calf plugins are designed from), CAPS and the Guitarix plugins packs.

@Linuxmusician01 I posted a link to it earlier in the thread as well but this site can be used to find specific things like: https://linuxmusic.rocks/category/phaser

[peter.zenk]

Rumours are that invada is also affected

https://discourse.ardour.org/t/ardour-8 ... ui/109936/

See close to the end of thread

[funkmuscle]

That has always been a problem with Linux. I read somewhere a while ago where they said it's basically the wild wild west out there because everybody is doing their own thing. Like for instance I heard calf plugins were developed for the developers personal use and then put it out there and in fact I hear that about a lot of the plugins.

I can't tell a developer what to do but I can suggest something that hopefully I don't get executed for it. I think if you're going to put it out there for others to use that just made it public so at that point shouldn't these things be developed for the user in mind instead of this is how I do it and if you like it you'll like it if you don't you don't. To me that throws everybody back that using this platform to make serious music.

Ardour/Mixbus and Reaper are basically the big two. Yes there's a bitwig and a few others but the ones mentioned before seem to be what people use the most. I could be wrong but from reading all over it seems to be those.

Maybe plug in developers before starting a project, contact the developers of the DAWs and collaborate with them so these things work hand in hand.

Again I'm just suggesting but I know a lot of people are setting their ways. In fact when I'm asked by friends before they want to jump to Linux, I say to them if you are not familiar with Sheldon from Big Bang theory, I suggest you get familiar with him because a lot of developers that you deal with at least in my personal opinion reminds me of him.

Again I'm not criticizing I'm just trying to look for solutions for us all. I really think we need some more harmony in the audio world of Linux. Just some standards to follow to avoid these kind of things and as I saw in another forum, if the developer is going to stop developing maybe just inform people to stop using their product because if somebody doesn't pick it up or fork it, we're going to be screwed.

Again they are not obligated to do that because a lot of developers just create stuff for their needs but I think that's fine but if you going to make it public, then it's no longer for your needs because you're going to have somebody else using it and at that point you're taking on more responsibilities so I think it's only fair to say that if you're done, you're done so people can move on and like if it's for your needs maybe still follow the guidelines once something is there to follow.

Please, I am not offending anyone I am just putting out suggestions. I know every time I put something here I'm very apologetic and I think it's because of PTSD dealing with people on the arch forums. They may have changed but I don't know because I'm so afraid of asking questions there because in the past I used to get scolded, tuned up, verbally abused before I would get a suggestion and I would be told stuff like go read the manual or search at the forums as if I didn't do that already but when the forums get big like for instance here, you do your searching and you don't find your answer then you ask and I find people in this forum are so willing to help so I come here first.

Developers keep up the great work because we truly appreciate it and those are just suggestions to help everybody out I hope.

[Daniele71]

Rumours are that invada is also affected

https://discourse.ardour.org/t/ardour-8 ... ui/109936/

See close to the end of thread

Sadly are facts, not rumors..

this is the list of packages that would be removed (only multimedia related packages) on my system (openSUSE TW):

Code: Select all

calf
fluidsynth-dssi 
kf5-mediainfo
lash
lv2-calf
lv2-calf-common
lv2-calf-transient-designer
lv2-calf-vintage-delay
lv2-drumrox
lv2-EQ10Q-plugins
lv2-invada-plugins
lv2-ir-1.2
mediainfo-gui
qtractor
rosegarden
sequencer64
suil-plugin-x11-in-gtk2
timidity
xsynth-dssi 

Qtractor and Rosegarden for some dependencies chains.

[bluebell]

CALF plugins are still in Debian stable ("Bookworm").

Chances are that Debian will keep gtk2 for a long time since Debian is not run by teenagers who love the newest hot shit – and don't care about people who just want to use computers to get things done instead of installing and learning new tools each couple of years.

Software is NOT deprecated when it's stable and boring for its developers.

[Linuxmusician01]

CALF plugins are still in Debian stable ("Bookworm").

Chances are that Debian will keep gtk2 for a long time since Debian is not run by teenagers who love the newest hot shit – and don't care about people who just want to use computers to get things done instead of installing and learning new tools each couple of years.

Software is NOT deprecated when it's stable and boring for its developers.

I'm afraid chances of that are nil. See one of the links above (Debian). It's impossible to keep on supporting stuff that depends on the deprecated and unmaintained libgtk2.0-0.

The real problem here is software (or development stuff, I don't know what to call it) that is not backwards compatible. Companies that do that should be banned from distributing their ever again! Remember the snafu with Python 2 to 3? Kodi (media center for Win, Lin, Xbox etc.) still had a ton of Pyhon 2 scripts in it a year or so ago which completely broke it. Linux is still filled with old Python 2 stuff. I bet you a million dollars nobody would have started to program in that sh*te if they knew their work would be deprecated after a while. You can still compile C programs that you wrote in 1983 and cutting edge triple A games are still developed in it. Thank you Brian Kernighan et al.

I hate Gtk and Python. If they ever suffer from a DDOS attack or their computers break because of ransomware you can send the police to my house because it's probably me. Fortunately I don't know how to program if my life depended on it so chances of Python and the GTk boys getting what they deserve are slim.

P.S I'm not sorry for the rant which is not anti-developer but against the organisations that dupe them. Shame on them!

[tramp]

The real problem here is software (or development stuff, I don't know what to call it) that is not backwards compatible. Companies that do that should be banned from distributing their ever again!

You shot a bit over the top. Checkout what we all get from GTK: https://en.wikipedia.org/wiki/List_of_GTK_applications
I guess you'll be surprised how much you use it yourself.
Also, the issue here isn't that much related to end of life of GTK2, but the wrong choice done by the initial LV2 development to support, yes, even force the use of, mainstream toolkits for plugin UI's. Time tell that this leads to a lot of trouble for users and developers.
If it was only about the end of life, well, there are so many way's to overcome that!
The very same issue comes sooner or later to QT based plugins as well.
However, development means work on the source and make it better. So, this include to skip previously supported actions which by time turns out to be the wrong choice. Development means, correct that! Otherwise, we all would use Paper to write Notes and analogue gear to produce sound. So, this day's we jump from version to version, that's true for software, but as well for hardware.

I hate Gtk and Python.

Python is still the best tool to develop developer tools and do proto typing. No other language could beat it. That's because it is fast to develop and use, has a very, very wide range of use-cases, and, yes, didn't waste time or resources by try to be smart to users. It's for developers.
I agree with you that providing user applications based on python is a bad idea, as python moves to fast for that, but, as a developer I'm very happy about having something like python.

And back on topic, it isn't really true that Calf plugins been bounded to GTK2. All plugin UI's been defined in xml files which then was interpreted by GTK to build the GUI. All what is needed to bring the Calf plugs back on track is, writing a xml interpreter for a other toolkit like BWidgets, LSPToolkit or libxputty and they could be back with the same old shiny interfaces.

[Linuxmusician01]

The real problem here is software (or development stuff, I don't know what to call it) that is not backwards compatible. Companies that do that should be banned from distributing their ever again!

You shot a bit over the top. Checkout what we all get from GTK: https://en.wikipedia.org/wiki/List_of_GTK_applications
I guess you'll be surprised how much you use it yourself.
Also, the issue here isn't that much related to end of life of GTK2, but the wrong choice done by the initial LV2 development to support, yes, even force the use of, mainstream toolkits for plugin UI's. Time tell that this leads to a lot of trouble for users and developers.
If it was only about the end of life, well, there are so many way's to overcome that!
The very same issue comes sooner or later to QT based plugins as well.
However, development means work on the source and make it better. So, this include to skip previously supported actions which by time turns out to be the wrong choice. Development means, correct that! Otherwise, we all would use Paper to write Notes and analogue gear to produce sound. So, this day's we jump from version to version, that's true for software, but as well for hardware.

I hate Gtk and Python.

Python is still the best tool to develop developer tools and do proto typing. No other language could beat it. That's because it is fast to develop and use, has a very, very wide range of use-cases, and, yes, didn't waste time or resources by try to be smart to users. It's for developers.
I agree with you that providing user applications based on python is a bad idea, as python moves to fast for that, but, as a developer I'm very happy about having something like python.

And back on topic, it isn't really true that Calf plugins been bounded to GTK2. All plugin UI's been defined in xml files which then was interpreted by GTK to build the GUI. All what is needed to bring the Calf plugs back on track is, writing a xml interpreter for a other toolkit like BWidgets, LSPToolkit or libxputty and they could be back with the same old shiny interfaces.

Thank you for taking my angry rant - me being a non-developer - seriously and kindly, like the grown-up that I myself ain't , explaining what's the problem and where I am wrong in assuming stuff.

The "problem" appears to be complex. I'm glad you say Python is (among others) best suited for prototyping. A friend of mine is in the (large) development team of the humongous behemoth of an application (or web interface, or whatever) for a big Bank. I dare not say to him that I frown upon Python because I don't know sh** about programming. Another friend of mine (also an IT guy) says that Python is a script for an interpreter (i.e. the actual Python executable), not a programming language. I'm afraid that the Python team at the Bank spends more time fixing problems that arise from Python "updates" that breaks stuff than actual development. Enter my gripe on the people developing Kodi Media Center in it.

Anyway, you said something fascinating on the Calf plugins: "All what is needed to bring the Calf plugs back on track is, writing a xml interpreter for a other toolkit like BWidgets, LSPToolkit or libxputty and they could be back with the same old shiny interfaces.". If that xml interpreter was part of Gtk (if I'm assuming that right, that is) is it the responsibility of the Gtk team to write another? Ad why isn't Gtk3 backwards compatible the interpreter?

Or was that xml interpreter written by the developer of Calf and can/should it be passed on to a possible developer who takes over the development of/support for Calf?

P.S. I don't dare to mention the backwards compatibility of Windows what many computer users are used to...

[RyanH]

Yes, LSP plugins are brilliant and offer so many possibilities, that I do not fully understand, especially when it comes to filter types and when to use what.
Maybe a reasonable bag of presets could help out.

Same for me. I can't say anything bad about options, except that it can become too much to wrap my mind around. Calf offers a good variety of parameters but not so much that I don't know how to use them.

It would be great if there was a button Advanced/Easy in the LSP plugins for us lesser Gods. I think that is the attraction of Calf plugins, easy to understand and beautiful skin.

I like that idea... although I wouldn't be the one trying to design it.

I have experimented with some plugins (I'm thinking mainly reverb) that I actually thought sounded a bit better than Calf, but used Calf instead because it was laid out in a way that I found easier to understand. (Ideally I would just gain a better understanding of how everything works, but with so many variables I have limited time/brain power to figure it all out. Kudos to those who are better at such things.)

[Michael Willis]

I have experimented with some plugins (I'm thinking mainly reverb) that I actually thought sounded a bit better than Calf, but used Calf instead because it was laid out in a way that I found easier to understand.

What plugins are you thinking of that sound better but ate harder to understand? I am because I want to develop some "easy mode" plugins. I can't make any promises about when they will be released because I'm also trying to hold down a day job and take care of a house full of children, but I've been actively looking at the source code for projects like Calf, Airwindows, blue lab, et. al. to see how they do their magic.

[funkmuscle]

I have experimented with some plugins (I'm thinking mainly reverb) that I actually thought sounded a bit better than Calf, but used Calf instead because it was laid out in a way that I found easier to understand.

What plugins are you thinking of that sound better but ate harder to understand? I am because I want to develop some "easy mode" plugins. I can't make any promises about when they will be released because I'm also trying to hold down a day job and take care of a house full of children, but I've been actively looking at the source code for projects like Calf, Airwindows, blue lab, et. al. to see how they do their magic.

Not sure if this goes in this topic but these are great plugins and maybe dead.
https://github.com/miland3r/eq10q

[Michael Willis]

Not sure if this goes in this topic but these are great plugins and maybe dead.
https://github.com/miland3r/eq10q

Thanks @funkmuscle, that's exactly the kind of thing I'm looking for. I only know enough about digital signal processing to get myself into trouble, but I feel like we have several old gems laying around that would be really great if they had some polish and were included in a suite of plugins with some more modern development standards. For example, some of the Calf plugins sound really good, but still don't have parameter smoothing, so automating some of the dials results in a zipper noise. I could make those kinds of improvements and bring some of these effects up to modern standards.

[marcellendi]

I have experimented with some plugins (I'm thinking mainly reverb) that I actually thought sounded a bit better than Calf, but used Calf instead because it was laid out in a way that I found easier to understand.

What plugins are you thinking of that sound better but ate harder to understand? I am because I want to develop some "easy mode" plugins. I can't make any promises about when they will be released because I'm also trying to hold down a day job and take care of a house full of children, but I've been actively looking at the source code for projects like Calf, Airwindows, blue lab, et. al. to see how they do their magic.

Can I help somehow in this? I am not a programmer though...