CLAP - Open Source Plugin Format
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
https://www.kvraudio.com/forum/viewtopi ... 1&t=574861
https://github.com/free-audio/clap
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...
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
I don't see this as reinventing the wheel, more like opening another wheel factory that offers different options.Loque wrote: ↑05 Jan 2022Yea, 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...
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
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
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?
"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
- integerpoet
- Posts: 832
- Joined: 30 Dec 2020
- Location: East Bay, California
- Contact:
selig wrote: ↑05 Jan 2022I 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).
- Shocker: I have a SoundCloud!
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)bxbrkrz wrote: ↑05 Jan 2022In 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?
false equivalenceintegerpoet wrote: ↑05 Jan 2022selig wrote: ↑05 Jan 2022I 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).
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
some wheels are better than others - just sayingLoque wrote: ↑05 Jan 2022Yea, 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...
PLUS, we know it’s possible to do so, look at MIDI as the best example in our industry.
Selig Audio, LLC
I see.jam-s wrote: ↑05 Jan 2022From 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)bxbrkrz wrote: ↑05 Jan 2022In 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
- willy_dinglefinger
- Posts: 44
- Joined: 18 Jun 2020
- Location: Scotland
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?
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
- integerpoet
- Posts: 832
- Joined: 30 Dec 2020
- Location: East Bay, California
- Contact:
(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.
false equivalencewith 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
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.
- Shocker: I have a SoundCloud!
hello
I just received an email from bitwig and I said it might be of interest to some
I just received an email from bitwig and I said it might be of interest to some
https://www.bitwig.com/stories/201/?utm ... 8d2c8ae53eHello, 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.
I just saw that the information was already relayed here 6 months ago . sorry
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?pongasoft wrote: ↑15 Jun 2022As 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.
VST is so omnipresent.
757365206C6F67696320746F207365656B20616E73776572732075736520726561736F6E20746F2066696E6420776973646F6D20676574206F7574206F6620796F757220636F6D666F7274207A6F6E65206F7220796F757220696E737069726174696F6E2077696C6C206372797374616C6C697A6520666F7265766572
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.
There is also a pending extension for "CV" ins and outs for devices.
Last edited by rcbuse on 15 Jun 2022, edited 2 times in total.
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)
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 )
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 )
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).Steedus wrote: ↑15 Jun 2022Bitwig & 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 )
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 2022I'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
-
- Information
-
Who is online
Users browsing this forum: No registered users and 1 guest