About CLAP

Official support for: u-he.com
Post Reply New Topic
RELATED
PRODUCTS

Post

And once more, Urs is the axe in the woods... I really like that.


So VST2 can survive, if somebody invests the time/resources to code a suitable wrapper with CLAP. No changes to the VST/VSTi in question needed. Question is: the additional processing overhead of the wrapper, and the stability.

Now I wonder which developer will break the ice on this first. :thinking:
Maybe Tone2, in parallel to a NanoHost update.


I will keep an eye on this... this move was indeed long overdue to rattle some cages.
[ Mix Challenge ] | [ Studio Page / Twitter ] | [ KVRmarks (see: metering tools) ]

Post

tony10000 wrote: Thu Jan 20, 2022 8:31 pmI 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?
I can't disclose who we're talking to. First off, there's no way to get a commitment at this point. Hence, if I told you "XY signalled interest in CLAP", there's no guarantee that it's going to happen. To the contrary, they might become uneasy if I was talking about them.

I'd love to get Steve on board, naturally. I think we ran into each other only once, almost 20 years ago, during a night out with Angus, Andy and pretty much everyone else. Steve knows where to find me, or Alexandre fwiw.

Post

Teksonik wrote: Thu Jan 20, 2022 8:44 pm
Teksonik wrote: Thu Jan 20, 2022 4:34 pm 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)
From what I have read, Bitwig and Reaper are on board.

Post

Teksonik wrote: Thu Jan 20, 2022 8:44 pm
Teksonik wrote: Thu Jan 20, 2022 4:34 pm 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)
Sorry if I missed the question, but I'm not a DAW developer, can't say how complex the task is, and I've repeatedly explained why DAW adoption rate isn't an issue for me.

Post

tony10000 wrote: Thu Jan 20, 2022 8:58 pmFrom what I have read, Bitwig and Reaper are on board.
While a fork of Reaper has been shown to support CLAP, I don't think there's an official statement from Cockos in that regard. I'm optimistic, but at this time nothing is set in stone.

Post

Urs wrote: Thu Jan 20, 2022 8:59 pm Sorry if I missed the question, but I'm not a DAW developer, can't say how complex the task is, and I've repeatedly explained why DAW adoption rate isn't an issue for me.
Ok well now I have to ask...why isn't adoption rate an issue? Sorry to make you repeat yourself but it seems like adoption would be pretty important otherwise what's the point?

Why would anyone use a plugin format our DAWs don't support? :shrug:
None are so hopelessly enslaved as those who falsely believe they are free. Johann Wolfgang von Goethe

Post

Because wrappers to other formats will exist.

The main issue CLAP is trying to solve is to have a clean and unencumbered license and a properly governed standard (VST is far from properly governed!) that makes it easy to develop a plugin once, then deply to other formats if need be. This is why host adoption is not a huge problem. If it happens, nice, if it doesn't, plugin devs are still benefitting from simplicity of CLAP (vs madness that is VST3).
Last edited by EvilDragon on Thu Jan 20, 2022 10:04 pm, edited 1 time in total.

Post

It's no an issue for me. We support CLAP because we can replace VST2 in our automated testing toolchain, preparing for the day when derivative work of VST2 can no longer be published anymore.

We also would like to explore the option to deploying either a CLAP-to-VST3 adapter or a CLAP-to-VST2 adapter so that we don't need to remove all our downloads containing VST2 anymore, should we wish to upgrade to the lastest VST3 SDK with its rather unsettling license terms, or vice-versa, should we not.

Post

As a total non coding lay person, I still have no idea what the clap actually is, but from reading here, it just seems like a pyramid scheme of wrappers... :?:

Post

AnX wrote: Thu Jan 20, 2022 10:07 pm As a total non coding lay person, I still have no idea what the clap actually is, but from reading here, it just seems like a pyramid scheme of wrappers... :?:
I kinda get what you're saying here, but this is the opposite of a pyramid scheme. No one's asking for money here. Urs isn't the head honcho collecting the big bucks from all the other suckers (excuse me, developers) he brings into the CLAP fold.

It's simple: it's a new, easy to develop for, open-source plugin format that may make it easier for developers to spit out plugins in other formats too.

If it lives up to what Urs' is describing, it may be win-win-win (developers-users-hosts).

Post

Funkybot's Evil Twin wrote: Thu Jan 20, 2022 10:21 pm It's simple: it's a new, easy to develop for, open-source plugin format that may make it easier for developers to spit out plugins in other formats too.
With benefits if supported natively such as polyphonic modulation, if I've understood the thread correctly up to this point.

Post

Just to explain a bit here, if memory doesn't completely fail me, the VST3 SDK once contained export functionality to AU and to VST2. So it started with a promise that if one developed for VST3, one would get AU and VST2 for free. I don't recall how that worked out, but obviously it's not uncommon to assume that some kind of interoperability is part of the concept behind a format.

Post

It's probably also worth emphasizing that in general plugin developers don't develope separate plugins for every API they support. Rather they develop their plugin against one API, whether that's some internal API, some toolkit (eg. Juce, iPlug) specific API, or some actual plugin API. Whatever other formats they support are then typically wrapped around that internal format. So if you're using some plugins that support multiple APIs, there's a very high chance that there's already some sort of wrappers involved.

When such wrappers are built into the plugin itself, it's essentially invisible to the users, but it can make quite a bit of difference to the developers and having a solid, open API can have quite a bit of value (to developers), even if no actual DAW ever supported it directly. If they do, then that's sort of a bonus.

Post

Well put!

Post

Urs wrote: Thu Jan 20, 2022 10:03 pm It's no an issue for me. We support CLAP because we can replace VST2 in our automated testing toolchain, preparing for the day when derivative work of VST2 can no longer be published anymore.

We also would like to explore the option to deploying either a CLAP-to-VST3 adapter or a CLAP-to-VST2 adapter so that we don't need to remove all our downloads containing VST2 anymore, should we wish to upgrade to the lastest VST3 SDK with its rather unsettling license terms, or vice-versa, should we not.
Ok fair enough. I thought the concept was to remove all dependencies on the VST format.

I was under the impression this was a new format to rid us of Steinberg's grip on the plugin world.

Seems more like a license workaround as you explain it but I wish you good luck no matter the end goal. :tu:
None are so hopelessly enslaved as those who falsely believe they are free. Johann Wolfgang von Goethe

Post Reply

Return to “u-he”