About CLAP

[Compyfox]

To me it isn't as much about replacing other formats as it is about removing the barriers between them, and to other platforms.

I get that. I am all for "one" format that everyone can work/develop in rather than have like how many? VST2/VST3/AU/AAX/Linux based/Max4DSP.

The problem resides with companies insisting on their "own thing", making it "their" problem rather than saying "okay... we set the ground rules, let the community do their thing".

This way, we'd only have to handle one(!) format (in this case: CLAP), not handle/workaround for several. It can remain backwards compatible, it can "evolve" with the times, etc.

Sadly... the big companies will never adhere to that (as in: implementing it), and certain tools will be lost forever (especially now with the announcement of "VST2 is dead - for real now, finally move on to VST3.x!!!!"). And as proven throughout the years, "wrapping" is also not the solution if you want a stable host.


As a mere user, I can do nothing but sit back, watch and wait. U-HE has been on the forefront of very, very interesting changes throughout the years (and thank you for that). But slowly also have to get used to the idea that the big companies send big f'n middle-fingers towards our way and how we want to use our tools.

[syntonica]

I'd also note that this is precisely why the GMPI effort took place back in the aughts, and why it was so tragic when the MMA f**ked that process up so badly that nothing ever came of it.

...except GMPI...

https://github.com/JeffMcClintock/GMPI (under construction, not all the code is up yet).

I like how there is an example of how small the plug-in code is in comparison to other formats, followed up with XML based parameter descriptions which add all the saved lines back in.

The XML is there, although it exhibits the usual abuse of metadata that makes me despise its use. I'm not sure that anything more than a simple key/value pair system is required. How much hierarchy can there be?

I did see a couple of nifty features, although I just quickly scanned the code.

That's indeed a terrible comparison graphic, though. The code hasn't been "normalized" to the same coding style and comments stripped.

[syntonica]

I get that. I am all for "one" format that everyone can work/develop in rather than have like how many? VST2/VST3/AU/AAX/Linux based/Max4DSP.

The problem resides with companies insisting on their "own thing", making it "their" problem rather than saying "okay... we set the ground rules, let the community do their thing".

This way, we'd only have to handle one(!) format (in this case: CLAP), not handle/workaround for several. It can remain backwards compatible, it can "evolve" with the times, etc.

Sadly... the big companies will never adhere to that (as in: implementing it), and certain tools will be lost forever (especially now with the announcement of "VST2 is dead - for real now, finally move on to VST3.x!!!!"). And as proven throughout the years, "wrapping" is also not the solution if you want a stable host.


As a mere user, I can do nothing but sit back, watch and wait. U-HE has been on the forefront of very, very interesting changes throughout the years (and thank you for that). But slowly also have to get used to the idea that the big companies send big f'n middle-fingers towards our way and how we want to use our tools.

Plugins have been wrapped for ages and are as stable as the format they emulate. More or less. Being able to develop one format only and get CLAP->VST2/3, CLAP->AU, etc., for free with bespoke wrappers can only help level the playing field and let devs focus on better DSP, which I imagine is why most devs got into the audio game in the first place. If they aspired to be richer than hundredaires, they'd be stock brokers.

[Compyfox]

Sadly, wrappers are not always "stable" - jBridge certainly wasn't.

Again, we have to sit this out. Especially now with the VST2 drama.

[Urs]

Plugins have been wrapped for ages and are as stable as the format they emulate. More or less. Being able to develop one format only and get CLAP->VST2/3, CLAP->AU, etc., for free with bespoke wrappers can only help level the playing field and let devs focus on better DSP, which I imagine is why most devs got into the audio game in the first place. If they aspired to be richer than hundredaires, they'd be stock brokers.

Yep.

The situation is: VST2 is going away. Many, many developers have to remove VST2 from their code base sooner or later, even though their code base is VST2 in the first place (even if they don't officially support VST2 anymore, there must not be any VST2 code or derivative work in the binary, obviously).

Also: VST2 license was never compatible with open source software, so we never saw robust open source wrappers.

The opportunity CLAP poses in this situation: Move code base to CLAP, and suddenly there's a good chance to get open source wrappers to popular formats, so that part of the work ahead may be avoidable. There's also a good chance that support/stability for formats like VST3 improves for individual developers who have struggled in the past (like us).

[audiojunkie]

Plugins have been wrapped for ages and are as stable as the format they emulate. More or less. Being able to develop one format only and get CLAP->VST2/3, CLAP->AU, etc., for free with bespoke wrappers can only help level the playing field and let devs focus on better DSP, which I imagine is why most devs got into the audio game in the first place. If they aspired to be richer than hundredaires, they'd be stock brokers.

Yep.

The situation is: VST2 is going away. Many, many developers have to remove VST2 from their code base sooner or later, even though their code base is VST2 in the first place (even if they don't officially support VST2 anymore, there must not be any VST2 code or derivative work in the binary, obviously).

Also: VST2 license was never compatible with open source software, so we never saw robust open source wrappers.

The opportunity CLAP poses in this situation: Move code base to CLAP, and suddenly there's a good chance to get open source wrappers to popular formats, so that part of the work ahead may be avoidable. There's also a good chance that support/stability for formats like VST3 improves for individual developers who have struggled in the past (like us).

So (at least part) of the idea is that VST2 developers can very quickly remove VST2 code, add CLAP code, and be back in business with little effort......and make a viable open source plugin format very popular very fast as a side effect.

[Urs]

So (at least part) of the idea is that VST2 developers can very quickly remove VST2 code, add CLAP code, and be back in business with little effort......and make a viable open source plugin format very popular very fast as a side effect.

It's one of the possible benefits of a simple, complete and liberally licensed plug-in ABI.

This doesn't apply to everyone, but I'm fairly certain that it may be an enticing option for some.

[Compyfox]

The opportunity CLAP poses in this situation: Move code base to CLAP, and suddenly there's a good chance to get open source wrappers to popular formats, so that part of the work ahead may be avoidable. There's also a good chance that support/stability for formats like VST3 improves for individual developers who have struggled in the past (like us).

Wait Urs... just to get you right.

Your concept (CLAP) could in theory create VST2 > VST3 wrappers, if there is code implemented in "CLAP's SDK"?

Or do developers need to write "CLAP CODE" into their VST3/AU/AAX plugins in order for wrappers to work? Much like "Here - you only need this one line of code so it works straight out of the box with jBridge"?


I am trying to see the light here that U-HE will release something in the foreseeable future, that makes it possible to continue using our VST2 plugins - no matter the age. Heck, maybe even even bridge the gap to use AAX or AU in a VST environmen (and the other way around).

If that is the case... where do I send my money to?

[Urs]

There are scenarios where CLAP can help to make VST2 plug-ins available in hosts which do not (anymore) support VST2. It is not a main incentive for us, nor is it without alternative. I.e. someone can create that anyway, no matter if CLAP is involved or not.

However, licensing is difficult. How to wrap VST2 to VST3 when the VST3 can't be GPLed and where at the same time it is in a state that is dismissive of VST2? Here, CLAP can be an intermediary: Closed source solution to wrap/adapt VST2 to CLAP from A, closed/open source solution to wrap/adapt CLAP to VST3 from B. While VST2 and VST3 will be mutually exclusive in their use, any liberally licensed plug-in format such as CLAP can act as a go between.

Which brings up the point that liberal licensing from the beginning would have made any of this unnecessary, and which is why a) "killing" VST2 is pointless and b) placing it in the public domain or under a liberal license would IMHO have been the better move.

[tony10000]

Will it address the MIDI limitations of VST 3?

viewtopic.php?t=574861

[teilo]

Will it address the MIDI limitations of VST 3?

viewtopic.php?t=574861

Yes, and that's been covered in this thread already. It supports both high-level note events, as well as raw MIDI.

[Urs]

CLAP doesn't have any limitation in regards to MIDI, but of course wrapping it to VST3 won't magically add that in. It can however utilise VST3's replacement technologies in full, which for many developers may be non-trivial otherwise.

For instance, I mentioned those developers who use VST2 as their base format. With VST2 in place, it's not trivial to support Note Expressions. If they wanted to swap VST2 for CLAP, they will have an easier time adding such features later on. And thus they can expand that to further formats such as VST3.

[tony10000]

CLAP doesn't have any limitation in regards to MIDI, but of course wrapping it to VST3 won't magically add that in. It can however utilise VST3's replacement technologies in full, which for many developers may be non-trivial otherwise.

For instance, I mentioned those developers who use VST2 as their base format. With VST2 in place, it's not trivial to support Note Expressions. If they wanted to swap VST2 for CLAP, they will have an easier time adding such features later on. And thus they can expand that to further formats such as VST3.

I have been discussing this situation with Steve Duda on Discord. He has stuck with VST2 because some of his apps (Cthulhu and Nerve) need it for its MIDI capabilities. He said he will look at CLAP if and when Ableton is on board. Any chance that Ableton and NI may support it?

[rafa1981]

There isn't one single VST3 plugin out there that I built from source code and went on actually using...

You completely misunderstood me or maybe my response wasn't clear, it doesn't really matter, what I was saying is that most commercial closed-source devs not providing Linux VST3 do so not because of how hard is to port, as many use Juce, but because of being afraid of having to support a very sparse ecosystem; lots of distros, versions of stuff, etc.

[Teksonik]

The question I would have at this time is how much work is it going to be for DAW developers to add CLAP plugin support?

Is this not an important question or am I missing something? (forgive me if it's been answered I just don't have time to read all 28 pages).

Even if all developers release CLAP versions of their plugins if DAWs are reluctant or slow to adopt the format that's going to be a problem right?

Now if it's a simple matter of a few lines of code it shouldn't be a big problem but if it's going to be an involved process requiring many man hours to add CLAP support then some DAW developers may not be motivated at least until there are enough CLAP plugins that the villagers will threaten to storm the castle if support is not added in their favorite DAWs.

I assume those involved with CLAP development are in contact with DAW developers to help make the adoption process easier? (yes I know Cubase for example is not likely to adopt)