Cool new plug in format on the way -- CLAP

[audiojunkie]

I might as well post it here as well......


Cool new plug in format on the way -- CLAP

https://www.kvraudio.com/forum/viewt...?f=31&t=574861


I'm left with way more questions than I have yet answers for. It seems (to me at least), to be a related continuation of what was started by developers in a thread that I posted about here:

https://forum.cockos.com/showthread.php?t=259967

At the very least, it seems to involve the same developers.

[porzione]

Not all developers will be happy to support yet another format, especially without solid reasons. I'm just wondering why u-he and Bitwig do that and why not use/extend lv2 instead.

[Glennbo]

Originally Posted by porzione

Not all developers will be happy to support yet another format, especially without solid reasons. I'm just wondering why u-he and Bitwig do that and why not use/extend lv2 instead.

Maybe it's easier to port from VST to CLAP than it is to port from VST to LV2. I dunno if it is, but that might enter the picture.

I try to always use the LV2 plugin if it is available over the same plugin done as a VST coz I much prefer using the open source format that will have no surprise licensing issues later down the line.

[audiojunkie]

Originally Posted by porzione

Not all developers will be happy to support yet another format, especially without solid reasons. I'm just wondering why u-he and Bitwig do that and why not use/extend lv2 instead.

This is a concern to me as well. It appears that there is a near universal distaste for the VST3SDK and all of the files it uses/creates/requires. Supposedly this new format improves vastly in this area. But it doesn't yet do midi plugins. They don't yet have a stable ABI. I worry that they have announced way too soon.

[audiojunkie]

Originally Posted by audiojunkie

This is a concern to me as well. It appears that there is a near universal distaste for the VST3SDK and all of the files it uses/creates/requires. Supposedly this new format improves vastly in this area. But it doesn't yet do midi plugins. They don't yet have a stable ABI. I worry that they have announced way too soon.

Apparently, it's incredibly easy to port, as per Urs:

"Several JUCE based open source synthesizer plug-ins have been ported to CLAP, almost literally overnite (I have to check chat protocols, but I do think I went to bed with one ported and woke up to yet another ported)."

[audiojunkie]

Also:

"The JUCE team itself expressed no apparent desire to deal with CLAP, but as it has been so easy to get basic support going, we're confident there'll be some header-only drop in available one day or another. Maybe we'll add one to the CLAP helper library."

[audiojunkie]

Also:

"BTW CLAP stands for CLever Audio Plugin."

[audiojunkie]

So, in short, we know that it is open source. It uses a lot less files than VST3SDK. Although JUCE doesn't support it, there is an easy way around that. And porting is incredibly easy. We know that the ABI isn't stable yet, and there are lots of changes going on. We know that it doesn't yet support Midi plugins.

Oh, and:

"The iPlug2 team on the other hand is very supportive to the cause."

[audiojunkie]

OK, maybe it DOES support MIDI plugins. See this:

"CLAP plug-ins can offer any number of MIDI input or output ports. They can process MIDI even if they don't process any audio at all.

(this is so obvious to me, I simply forgot to mention it)"

[cern.th.skei]

i made a simple synth while learning clap
https://www.youtube.com/watch?v=ffEu9A6Pzow
a very pleasant api to work with

[audiojunkie]

Originally Posted by cern.th.skei

i made a simple synth while learning clap
https://www.youtube.com/watch?v=ffEu9A6Pzow
a very pleasant api to work with

Interesting! What can you tell us about CLAP? Do you think it will help audio on Linux?

EDIT: We're not talking about the command line parser, BTW...

[cern.th.skei]

can't say much about it, other than what others have already posted.. or, more correctly, i'm just a helping with some smaller stuff, so i'm probably not 'authorized' to be a spokes-person :-) but it looks like it's beginning to open up now..

and, no idea if it will help linux.. i can only hope, and do my (little) part.. i guess people choose what plugin formats they want to use or make because of different things than just the code/api itself.. but the api is very clean and well-defined.. good for beginners/amateurs.. and it's very easy to incorporate into an existing frameworks.. it's cross-platform and mit licensed, so if somebody makes a clap plugin for windows or mac, it could be easier for them to compile a linux clap version too, than port it specifically to lv2, or try to bend their existing framework around lv2.. so, maybe it will help.. but as i said, i have absolutely no idea, i'm just daydreaming.. :-)

regarding the mentioned 'my little part':
https://github.com/skei/MIP

[wastee]

Thanks for the news!
The good way is give up steinberg things. The bad way is one more open standers plugin format... more mess maybe.

[PMan]

The audio dev community has been unhappy with the handling of the VST standard for a while now, especially since VST3 happened.

Reaper supporting LV2 and now plugin devs like U-He getting behind CLAP... It sounds like people are unhappy enough to take action. I hope it takes off.

The good thing is that it's not an either/or situation. The CLAP standard can exist alongside the proprietary ones. If a few more hosts like *ehem* Reaper support it, it stands a good chance.

The proprietary formats won't go away, but if CLAP takes off, many smaller devs will not bother to jump through the proprietary hoops. That is already the case with some plugins being Windows/VST only. Right now Windows/VST is the easiest route, Windows/CLAP would be even easier. That is a good thing.

What is even more interesting question here is how other large, corporate devs will respond. Only one dev benefits from the VST format - Steinberg. I'm sure the other devs - large and small - would be happy to see Steinberg have less influence on the industry.

Will this *directly* benefit Linux audio? A well supported non-proprietary plugin standard will benefit all platforms, including Linux. It won't bring more *users* to Linux, but that's ok. The increasingly heavy handed tactics of Microsoft and Apple will cause more people to try Linux than any plugin spec, just like the tactics of Steinberg and Apple are causing devs to try alternatives.

History has a way of repeating itself - IBM was invincible... until they created the Microsoft/Intel franchise. Microsoft/Windows was invincible... until Steve Jobs brought Apple back. Intel was invincible... until Lisa Su brought AMD back (and Apple started making their own chips).

No company or standard is invincible. Not Apple, and not Steinberg.

[nofish]

Originally Posted by cern.th.skei

i made a simple synth while learning clap
https://www.youtube.com/watch?v=ffEu9A6Pzow
a very pleasant api to work with

Is that Bitwig you're testing it in?
So Bitwig already supports CLAP?

[cern.th.skei]

Originally Posted by nofish

Is that Bitwig you're testing it in?
So Bitwig already supports CLAP?

can't say much more than what urs said here:
https://www.kvraudio.com/forum/viewtopic.php?p=8296043
"some cool open source projects are already running as CLAP in private branches"

[nofish]

I guess time will tell.
Thanks.

[mschnell]

Originally Posted by Glennbo

Maybe it's easier to port from VST to CLAP than it is to port from VST to LV2.

As there is VST3 for Linux, why would that be necessary ?

-Michael

[PMan]

"why would that be necessary ? "

Great question. Urs from u-he lays it out in post #16 (on page 6) from that thread:

"The question "so who's gonna support it?" is pretty much what has killed all prior efforts to do this. So we took it out of the equation. It's simply not important.

For any developer who starts out or wants to have a solid base, CLAP is gonna be an easy choice. All other formats can be abstracted from it. For AU we (u-he, not CLAP devs) have planned to offer a CLAP-to-AU wrapper for developers. So you do CLAP, you get AU for free. For some other formats it's possible to create open source adapters, for some it needs to be closed source. The host manufacturers can deploy these adapters themselves, the plug-in manufacturers can add them to their CLAP installers, or the users can install them.

The gist is: A CLAP plug-in can tell its wrappers and adapters what it would be like if it was that kind of plug-in. So developers can smoothly transition their existing codebase to CLAP and still support pretty much all other formats as if they were developing for these directly. Additionally, hosts can "upgrade" any legacy format to the CLAP counterparts of the plug-ins. SO if people lose the ability to keep their VST2 plug-ins up to date, a host that supports CLAP can open old projects and switch to CLAP instead, with minimum effort on the plug-in developer side.

Another goal is to separate ones own development from the actual development of plug-in formats. Syncing changes in plug-in formats isn't always easy and it has slowed us down several times. It's a good idea to abstract whatever plug-in format in a way that keeps one's own code independent of the specifics of plug-in formats and/or platforms. CLAP lends itself to be the intermediate layer. Moreover, developers can share the CLAP-to-X adapters and thus bypass the extra effort to support these. Stuff like that pretty much only works with open formats and it'll overall improve compatibility.

Hence, even if no host is ever gonna support it (I doubt they won't... because... well), CLAP can deliver an added value to developers."

- - - -

Among all of the other goodies in that post is this little golden nugget about cross-platform compatibility:

"It's a good idea to abstract whatever plug-in format in a way that keeps one's own code independent of the specifics of plug-in formats and/or platforms. CLAP lends itself to be the intermediate layer."

These people are freakin' brilliant!

[FeedTheCat]

Looks like schwa (the other cockos guy) has been testing CLAP (link). Exciting!

[vitalker]

Originally Posted by FeedTheCat

Looks like schwa (the other cockos guy) has been testing CLAP (link). Exciting!

Haha, very nice! How did you find it?

[FeedTheCat]

Originally Posted by vitalker

Haha, very nice! How did you find it?

Was actually looking into CLAP when I stumbled upon something named schwa.. which seemed a bit familiar :P

[vitalker]

Originally Posted by FeedTheCat

Was actually looking into CLAP when I stumbled upon something named schwa.. which seemed a bit familiar :P

Yep, you even quoted him in the previous comment. All right, interesting.

[audiojunkie]

Cool!! 😎👍🏼

[wastee]

Originally Posted by FeedTheCat

Looks like schwa (the other cockos guy) has been testing CLAP (link). Exciting!

Wow! Seems a lot chance to support it officially in near feature.

[audiojunkie]

Supposedly, this should make development much easier across the board--even for Linux.

[pcp]

Jürgen Moßgraber (Driven By Moss) has a new video up about it. It sounds very interesting quite apart from the open-source aspect. The polyphonic parameter modulation / ARA stuff and the ability for plugins to properly coordinate multi-threading with the DAW look really great - Urs Heckman said the real-world performance boost to his instruments is already eye-popping.

https://www.youtube.com/watch?v=HE-jerTn04w

And Schwa's repo seems to be coming along well, it looks straightforward to prototype CLAP plugins in REAPER already.

[d.igital]

From KVR, the domain is all linked up etc.

https://cleveraudio.org

Just bumping TBH, I'm hoping to see support in Reaper sooner rather than later.

[audiojunkie]

Originally Posted by d.igital

From KVR, the domain is all linked up etc.

https://cleveraudio.org

Just bumping TBH, I'm hoping to see support in Reaper sooner rather than later.

Very nice!

[d.igital]

An article with some history on LWN.

https://lwn.net/Articles/893048/

Apologies if I'm reporting stuff that you guys are already aware of, I'm a bit new around here.

[audiojunkie]

Originally Posted by d.igital

An article with some history on LWN.

https://lwn.net/Articles/893048/

Apologies if I'm reporting stuff that you guys are already aware of, I'm a bit new around here.

Excellent article!! There was a lot of new information that I didn’t know but learned—and I’ve read everything I can find on the topic! Thanks for posting this!


EDIT: Wow! What a surprise!! They quoted me in an early comment from the days when clap was announced. I’m a lot more enthusiastic about CLAP now than I was then.

[anotherzen]

Info is out: https://u-he.com/community/clap/

Some big names on the list for Projects to watch out for. Exciting stuffs.

[krahosk]

The greatest thing about CLAP is its open source and liberal license: no fees, memberships or proprietary license agreements.

[chmaha]

Originally Posted by krahosk

The greatest thing about CLAP is its open source and liberal license: no fees, memberships or proprietary license agreements.

But isn't that also true of LV2?

[X-Raym]

[SmajjL]

If the benchmarks are "eye-popping" then i'm sure curious now on seeing how Divas playing the same thing with an CPU-expensive patch going until it crackles, how many track one can duplicate

[audiojunkie]

Originally Posted by SmajjL

If the benchmarks are "eye-popping" then i'm sure curious now on seeing how Divas playing the same thing with an CPU-expensive patch going until it crackles, how many track one can duplicate

That's marketing for you. I'd rather they under promise and over deliver, than over promise and under deliver.

[mike@overtonedsp]

I wish they'd chosen a better / different backronym

On a more technical note, not sure how this solves issues that LV2 had / or better than LV2? You can add custom extensions to VST3 (and actually VST2 also) provided the host / plug-in support them so, broadly speaking, not much difference as far as I can tell.
The only thing (from an open source perspective) is the licensing, but as far as I know the VST3 licensing can be compatible with open source licenses). Is anyone on e.g. Windows or Mac crying out for Yet Another Plug-In Format (tm) or is this just a Linux thing (in which case, (how) does this solve the single most awkward, and potential troublesome thing about coding plug-ins for Linux which has always been the GUI support?)

As someone who wants to see greater adoption of Linux as a platform for pro-audio production, I'm a little concerned that this is an unnecessary diversion from encouraging more ports to Linux of existing plug-ins, and that might not be a price worth paying if it doesn't bring anything genuinely groundbreaking.

To quote from the lwn article (my emphasis) :

Developers want to write once and be able to compile for all architectures, OSes, etc. JUCE is the de-facto standard and overall king in this realm. Without JUCE buy-in, a new format will just muddy up the waters for development and be another thing that users will think they want developers to support, and developers will hate it for that reason. If this format doesn't solve more than the Steinberg licensing problem, it's not likely to help anyone.

I don't use JUCE, but its a fact that many plug-ins do, and that in many ways that makes them relatively easy to port to Linux VST / VST3 as is. Surely that's where the focus really needs to be, to encourage greater uptake of Linux for audio - then the rest will follow

[chmaha]

Originally Posted by mike@overtonedsp

As someone who wants to see greater adoption of Linux as a platform for pro-audio production, I'm a little concerned that this is an unnecessary diversion from encouraging more ports to Linux of existing plug-ins, and that might not be a price worth paying if it doesn't bring anything genuinely groundbreaking.

Agreed. I hope I'm wrong but this feels like needlessly re-inventing the wheel. Why not just help improve LV2, or, as you say, just continue to port VST3 to Linux?

[SmajjL]

Originally Posted by mike@overtonedsp

I wish they'd chosen a better / different backronym

On a more technical note, not sure how this solves issues that LV2 had / or better than LV2? You can add custom extensions to VST3 (and actually VST2 also) provided the host / plug-in support them so, broadly speaking, not much difference as far as I can tell.
The only thing (from an open source perspective) is the licensing, but as far as I know the VST3 licensing can be compatible with open source licenses). Is anyone on e.g. Windows or Mac crying out for Yet Another Plug-In Format (tm) or is this just a Linux thing (in which case, (how) does this solve the single most awkward, and potential troublesome thing about coding plug-ins for Linux which has always been the GUI support?)

As someone who wants to see greater adoption of Linux as a platform for pro-audio production, I'm a little concerned that this is an unnecessary diversion from encouraging more ports to Linux of existing plug-ins, and that might not be a price worth paying if it doesn't bring anything genuinely groundbreaking.

To quote from the lwn article (my emphasis) :



I don't use JUCE, but its a fact that many plug-ins do, and that in many ways that makes them relatively easy to port to Linux VST / VST3 as is. Surely that's where the focus really needs to be, to encourage greater uptake of Linux for audio - then the rest will follow

Not sure Our Devs will answer this, But even Cockos seems interested as in seeing something useful, otherwise they would not Dev for it, and Cockos is not the only one as you saw interested Deving for it
I am curious also and maby you can post this at https://www.kvraudio.com/forum/viewtopic.php?p=8296043 because good questions deserves to be answered, its teh unwritten-LAW