CLAP - Open Source Plugin Format

Want to talk about music hardware or software that doesn't include Reason?
User avatar
Despondo
Competition Winner
Posts: 1030
Joined: 15 Jan 2015
Location: Charlotte, NC
Contact:

05 Jan 2022

Not sure if anyone has heard of this, but there is an alternative open source plugin format being developed and supported by the likes of U-He, Bitwig and others. Just mentioning it here so others can keep an eye on its development.

https://www.kvraudio.com/forum/viewtopi ... 1&t=574861

https://github.com/free-audio/clap

User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

05 Jan 2022

Yea, lets reinvent the wheel. We can make it rounder than others...

One thing that is missing and is obviously the biggest drawback, that if a dev does not update or recompile its plugins, you are doomed. So many interesting VSTs out there, still at 32bit or never got updated to any newer OS...
Reason12, Win10

User avatar
selig
RE Developer
Posts: 11685
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

05 Jan 2022

Loque wrote:
05 Jan 2022
Yea, lets reinvent the wheel. We can make it rounder than others...

One thing that is missing and is obviously the biggest drawback, that if a dev does not update or recompile its plugins, you are doomed. So many interesting VSTs out there, still at 32bit or never got updated to any newer OS...
I don't see this as reinventing the wheel, more like opening another wheel factory that offers different options.
IMO Reason Studios didn't re-invent the wheel either with REs, nor did Apple with AU.
Even VST followed Pro Tools with a second plugin format a good 4-5 years later (Waves Q-10 was released around 1992, Pro Tools in 1991), and I would say it's good to have options - especially open source (like MIDI).
Selig Audio, LLC

User avatar
orthodox
RE Developer
Posts: 2286
Joined: 22 Jan 2015
Location: 55°09'24.5"N 37°27'41.4"E

05 Jan 2022

Loque wrote:
05 Jan 2022
One thing that is missing and is obviously the biggest drawback, that if a dev does not update or recompile its plugins, you are doomed. So many interesting VSTs out there, still at 32bit or never got updated to any newer OS...
If the mentioned plugins were open-source, anybody could raise the fallen banner and go on with the development.

User avatar
Loque
Moderator
Posts: 11175
Joined: 28 Dec 2015

05 Jan 2022

orthodox wrote:
05 Jan 2022
Loque wrote:
05 Jan 2022
One thing that is missing and is obviously the biggest drawback, that if a dev does not update or recompile its plugins, you are doomed. So many interesting VSTs out there, still at 32bit or never got updated to any newer OS...
If the mentioned plugins were open-source, anybody could raise the fallen banner and go on with the development.
Hum...yea...if someone is willing to do it.

I just checked my VCV account and there is a big bunch of racks which never got updated. Good, that i mainly use the core stuff if possible. Maybe someone will port the racks sometime in the future...yea...if they are OOS of course ;-)
Reason12, Win10

User avatar
bxbrkrz
Posts: 3812
Joined: 17 Jan 2015

05 Jan 2022

In the original link in the thread I read:

"Cubase/Steinberg may indeed be the hardest sell, but they also are a huge part of why an open modern standard is needed that isn't tied to a company that is pushing it's ideas down developers throats.
The story of VST3 was a complete disaster and the behaviour of Steinberg in that regard a real eye opener for many devs I think."


What's the problem with VST3, from a dev's experience?
757365206C6F67696320746F207365656B20616E73776572732075736520726561736F6E20746F2066696E6420776973646F6D20676574206F7574206F6620796F757220636F6D666F7274207A6F6E65206F7220796F757220696E737069726174696F6E2077696C6C206372797374616C6C697A6520666F7265766572

User avatar
integerpoet
Posts: 832
Joined: 30 Dec 2020
Location: East Bay, California
Contact:

05 Jan 2022

selig wrote:
05 Jan 2022
I don't see this as reinventing the wheel, more like opening another wheel factory that offers different options.
IMO Reason Studios didn't re-invent the wheel either with REs, nor did Apple with AU.
Even VST followed Pro Tools with a second plugin format a good 4-5 years later (Waves Q-10 was released around 1992, Pro Tools in 1991), and I would say it's good to have options - especially open source (like MIDI).
Image

User avatar
jam-s
Posts: 3035
Joined: 17 Apr 2015
Location: Aachen, Germany
Contact:

05 Jan 2022

bxbrkrz wrote:
05 Jan 2022
In the original link in the thread I read:

"Cubase/Steinberg may indeed be the hardest sell, but they also are a huge part of why an open modern standard is needed that isn't tied to a company that is pushing it's ideas down developers throats.
The story of VST3 was a complete disaster and the behaviour of Steinberg in that regard a real eye opener for many devs I think."


What's the problem with VST3, from a dev's experience?
From what I've picked up: A much too complicated (blown out of proportion) mandatory to implement API in comparison to VST2.4 and no real benefit in return. (https://www.kvraudio.com/forum/viewtopic.php?t=284062)

User avatar
DaveyG
Posts: 2499
Joined: 03 May 2020

06 Jan 2022

I think it probably won't catch on without the support of at least one of the big players but maybe we should start the campaign to get it added to Reason now so we have a chance for it to be added in five or ten years from now.

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

06 Jan 2022

integerpoet wrote:
05 Jan 2022
selig wrote:
05 Jan 2022
I don't see this as reinventing the wheel, more like opening another wheel factory that offers different options.
IMO Reason Studios didn't re-invent the wheel either with REs, nor did Apple with AU.
Even VST followed Pro Tools with a second plugin format a good 4-5 years later (Waves Q-10 was released around 1992, Pro Tools in 1991), and I would say it's good to have options - especially open source (like MIDI).
Image
false equivalence

with that thinking we wouldn't have had Java or python, or JavaScript, or Google Chrome, or Linux ... or Reason because other stuff existed before to meet needs

VariableX
Posts: 564
Joined: 02 Apr 2018

06 Jan 2022

Loque wrote:
05 Jan 2022
Yea, lets reinvent the wheel. We can make it rounder than others...

One thing that is missing and is obviously the biggest drawback, that if a dev does not update or recompile its plugins, you are doomed. So many interesting VSTs out there, still at 32bit or never got updated to any newer OS...
some wheels are better than others - just saying 😀

User avatar
selig
RE Developer
Posts: 11685
Joined: 15 Jan 2015
Location: The NorthWoods, CT, USA

06 Jan 2022

avasopht wrote:
06 Jan 2022
integerpoet wrote:
05 Jan 2022

Image
false equivalence

with that thinking we wouldn't have had Java or python, or JavaScript, or Google Chrome, or Linux ... or Reason because other stuff existed before to meet needs
PLUS, we know it’s possible to do so, look at MIDI as the best example in our industry.
Selig Audio, LLC

User avatar
bxbrkrz
Posts: 3812
Joined: 17 Jan 2015

06 Jan 2022

jam-s wrote:
05 Jan 2022
bxbrkrz wrote:
05 Jan 2022
In the original link in the thread I read:

"Cubase/Steinberg may indeed be the hardest sell, but they also are a huge part of why an open modern standard is needed that isn't tied to a company that is pushing it's ideas down developers throats.
The story of VST3 was a complete disaster and the behaviour of Steinberg in that regard a real eye opener for many devs I think."


What's the problem with VST3, from a dev's experience?
From what I've picked up: A much too complicated (blown out of proportion) mandatory to implement API in comparison to VST2.4 and no real benefit in return. (https://www.kvraudio.com/forum/viewtopic.php?t=284062)
I see.
757365206C6F67696320746F207365656B20616E73776572732075736520726561736F6E20746F2066696E6420776973646F6D20676574206F7574206F6620796F757220636F6D666F7274207A6F6E65206F7220796F757220696E737069726174696F6E2077696C6C206372797374616C6C697A6520666F7265766572

User avatar
willy_dinglefinger
Posts: 44
Joined: 18 Jun 2020
Location: Scotland

07 Jan 2022

I'm not a programmer at all so forgive me if this is a stupid question, but why not just push and develop the LV2 plug standard instead of creating a new one?

I asked this on the Renoise forum a couple weeks ago but the only response was akin to 'because lv2 is not good.' Surely there's more to it though?
Hypernormalise forum signatures :reason:

User avatar
integerpoet
Posts: 832
Joined: 30 Dec 2020
Location: East Bay, California
Contact:

07 Jan 2022

avasopht wrote:
06 Jan 2022
integerpoet wrote:
05 Jan 2022
(a comic)
false equivalence
(sigh) No, comedy. It's about the hubris of imagining a new standard will conquer all the others by means of its towering superiority and create world peace. It's a little like hitting the Submit button in a web forum argument. No, there will be no satisfying triumph. But I'm not arguing they shouldn't do what they propose.
with that thinking we wouldn't have had Java or python, or JavaScript, or Google Chrome, or Linux ... or Reason because other stuff existed before to meet needs
false equivalence

Bwa ha ha! It's funny because now I'm serious! :-) Those are products, not standards. If you had set up an argument involving something like JVM vs LLVM or Java vs Kotlin or V8 vs Spider Monkey (or or or or), we'd have something to scrap about, but only 1% of the audience would have any idea what we were saying. :-)

But really, let's not argue. I was just posting a funny comic. I have zero interest in debating whether to launch a new standard. Those wheels turn much more bigly than mine.

If it helps, I actually thought the originators showed some insight. I just think they're up against a lot of inertia and I'm glad I lack their passion for the problem space because they're signing up for a long slog.

User avatar
Kilsane
Posts: 276
Joined: 15 Sep 2016
Location: Villeneuve saint Georges - France
Contact:

15 Jun 2022

hello
I just received an email from bitwig and I said it might be of interest to some
Hello, it's great to see you, as we have an exciting announcement. Together with u‑he, we're happy to introduce CLAP, an open, modern, and free plug-in standard.

Audio plug-ins and host applications like DAWs share a vital mission: to help creators produce audio and make music. CLAP (Clever Audio Plug-in API) brings performance leaps and new possibilities, clarity and support to simplify developer effort, and an open source model that is a safe investment for all.
https://www.bitwig.com/stories/201/?utm ... 8d2c8ae53e

User avatar
Kilsane
Posts: 276
Joined: 15 Sep 2016
Location: Villeneuve saint Georges - France
Contact:

15 Jun 2022

I just saw that the information was already relayed here 6 months ago 😁 . sorry

User avatar
pongasoft
RE Developer
Posts: 478
Joined: 21 Apr 2016
Location: Las Vegas
Contact:

15 Jun 2022

bxbrkrz wrote:
05 Jan 2022
What's the problem with VST3, from a dev's experience?
As a plugin developer, I think VST3 was a good idea originally. The main problem is that Steinberg, who owns it, is one of the worst when it comes to software API and lifecycle.

First of all VST2 might have been limited but it was highly successful and simple to use. As a result thousands of plugins have been written for the VST2 format.

When Steinberg decided to switch to VST3, they essentially killed VST2 and by they way NEVER provided an easy path for developers to migrate to VST3. For example, it would have been somewhat easy for them to provide a VST3 wrapper that can run any VST2 plugin.

VST3 is huge in comparison to VST2, so much harder to get into and they keep making changes to it without community feedback (so they do whatever they want for their own purposes, not the community at large). They do not know what it means to handle the software from a programmer point of view: they change API willy-nilly, most of the time breaking code. Every time they release a new SDK, the previous one is no longer available (I have never seen any kind of software project do this!)... you can only download the "latest" SDK (to be fair the code is available on github so you can "go back" and get a previous version, but the code on github is NOT the entire SDK as the SDK contains tools that are not on github... so it's not the same).

Finally VST3 is not really open source. You can see the code, but they don't allow the community to make changes to it. And if you want to use it for a commercial product you have to get a License from Steinberg.

I would absolutely love to have a truly open source audio plugin format supported by all DAWs. The only reason I am doing VST3 right now is because it runs on most platforms. But would be more than happy to ditch it for something truly open.

User avatar
DaveyG
Posts: 2499
Joined: 03 May 2020

15 Jun 2022

pongasoft wrote:
15 Jun 2022
The only reason I am doing VST3 right now is because it runs on most platforms. But would be more than happy to ditch it for something truly open.
The problem might be that you, and every other DEV, end up having to do CLAP in addition to VST3 rathe than instead of it.

User avatar
bxbrkrz
Posts: 3812
Joined: 17 Jan 2015

15 Jun 2022

pongasoft wrote:
15 Jun 2022
bxbrkrz wrote:
05 Jan 2022
What's the problem with VST3, from a dev's experience?
As a plugin developer, I think VST3 was a good idea originally. The main problem is that Steinberg, who owns it, is one of the worst when it comes to software API and lifecycle.

First of all VST2 might have been limited but it was highly successful and simple to use. As a result thousands of plugins have been written for the VST2 format.

When Steinberg decided to switch to VST3, they essentially killed VST2 and by they way NEVER provided an easy path for developers to migrate to VST3. For example, it would have been somewhat easy for them to provide a VST3 wrapper that can run any VST2 plugin.

VST3 is huge in comparison to VST2, so much harder to get into and they keep making changes to it without community feedback (so they do whatever they want for their own purposes, not the community at large). They do not know what it means to handle the software from a programmer point of view: they change API willy-nilly, most of the time breaking code. Every time they release a new SDK, the previous one is no longer available (I have never seen any kind of software project do this!)... you can only download the "latest" SDK (to be fair the code is available on github so you can "go back" and get a previous version, but the code on github is NOT the entire SDK as the SDK contains tools that are not on github... so it's not the same).

Finally VST3 is not really open source. You can see the code, but they don't allow the community to make changes to it. And if you want to use it for a commercial product you have to get a License from Steinberg.

I would absolutely love to have a truly open source audio plugin format supported by all DAWs. The only reason I am doing VST3 right now is because it runs on most platforms. But would be more than happy to ditch it for something truly open.
Is there a way for all devs to push back, all at once? I remember DXi used to be a thing. DXi2? :puf_smile:
VST is so omnipresent.
757365206C6F67696320746F207365656B20616E73776572732075736520726561736F6E20746F2066696E6420776973646F6D20676574206F7574206F6620796F757220636F6D666F7274207A6F6E65206F7220796F757220696E737069726174696F6E2077696C6C206372797374616C6C697A6520666F7265766572

User avatar
rcbuse
RE Developer
Posts: 1175
Joined: 16 Jan 2015
Location: SR388
Contact:

15 Jun 2022

I've been playing around with CLAP these past few months. The per-voice non-destructive modulation is awesome. For anyone that doesn't know what that is, that allows you to place parameter modulation outside of the device, and it works polyphonically. So you can separate your 'synth' from your modulation. A synth developer can concentrate on the sound engine and not have to re-write a lfo/envelope/modulation matrix on each device. Devices become much more compact and your modulation choices become unlimited. A new envelope or LFO gets created with each note on. There is also per-note expressions, which is in VST3 and also supported by MPE, but I think CLAP takes it further.

There is also a pending extension for "CV" ins and outs for devices.
BitwigModulation2.jpg
BitwigModulation2.jpg (403.34 KiB) Viewed 4110 times
Last edited by rcbuse on 15 Jun 2022, edited 2 times in total.

User avatar
rcbuse
RE Developer
Posts: 1175
Joined: 16 Jan 2015
Location: SR388
Contact:

15 Jun 2022

DaveyG wrote:
15 Jun 2022
pongasoft wrote:
15 Jun 2022
The only reason I am doing VST3 right now is because it runs on most platforms. But would be more than happy to ditch it for something truly open.
The problem might be that you, and every other DEV, end up having to do CLAP in addition to VST3 rathe than instead of it.
I'm 99% sure that once things get rolling that there will be a CLAP to VST / AU / Whatever adapter. So the developer only needs to write to CLAP and then just rebuild for the others. (If it doesn't already exist)

Steedus
Competition Winner
Posts: 1009
Joined: 31 Aug 2015
Location: Melbourne, AU

15 Jun 2022

Bitwig & u-he have announced yet another plug-in format called CLAP (CLever Audio Plug-in API)

https://www.bitwig.com/stories/clap-the ... ndard-201/



Looks like it can do some extra stuff with automation/modulation etc.

Is this like another VST / AAX / AU, or is it more the internal code inside one of those wrappers? (I'm not a programming guy :oops: )

avasopht
Competition Winner
Posts: 3932
Joined: 16 Jan 2015

15 Jun 2022

Steedus wrote:
15 Jun 2022
Bitwig & u-he have announced yet another plug-in format called CLAP (CLever Audio Plug-in API)

https://www.bitwig.com/stories/clap-the ... ndard-201/



Looks like it can do some extra stuff with automation/modulation etc.

Is this like another VST / AAX / AU, or is it more the internal code inside one of those wrappers? (I'm not a programming guy :oops: )
There are key differences for developers (and offers some new features that you'll see as a user). Basically it's just a better and smoother standard to implement, plus it has some additional features (which they've explained in their thread about it).


It makes it possible for the DAW to coordinate the allocation of cores to CLAP plugins (nothing like this is possible with VSTs). This improves efficiency.

They explain the differences over on KVR.
rcbuse wrote:
15 Jun 2022
I've been playing around with CLAP these past few months. The per-voice non-destructive modulation is awesome. For anyone that doesn't know what that is, that allows you to place parameter modulation outside of the device, and it works polyphonically. So you can separate your 'synth' from your modulation. A synth developer can concentrate on the sound engine and not have to re-write a lfo/envelope/modulation matrix on each device. Devices become much more compact and your modulation choices become unlimited. A new envelope or LFO gets created with each note on. There is also per-note expressions, which is in VST3 and also supported by MPE, but I think CLAP takes it further.

There is also a pending extension for "CV" ins and outs for devices.

BitwigModulation2.jpg

Steedus
Competition Winner
Posts: 1009
Joined: 31 Aug 2015
Location: Melbourne, AU

15 Jun 2022

Awesome thanks!

Post Reply
  • Information
  • Who is online

    Users browsing this forum: No registered users and 9 guests