CLAP... thoughts?

[sQeetz]

If those plugins were created from VST2 core then wrapped into other formats, as majority of plugins out there really are, coupled with the fact that Steinberg can force devs to remove every trace of VST2 code from their build systems if they sign an updated VST3 license agreement (which they would have to do in order to be able to produce VST3 plugins!), the incentive is more than sufficient to replace that VST2 core with CLAP.

In theory. But which developer who still uses VST2 code will give a crap about that?

[EvilDragon]

All of them. The danger of Steinberg pulling such a stunt again is very real. You obviously haven't been around last year when this stuff was playing out in realtime and a bunch of devs raised pitchforks.

to create another bottleneck?

There's no bottleneck, when actual devs out there have been porting their existing plugins (regardless of format) to CLAP within a day!

You cannot compare this with a completely different CPU architecture shift.

[baconpaul]

Pdxindy - you should really try surge too if you haven’t. From hearing you speak about the uhe synths I bet you will love it

As to daws - on launch day bitwig and MultitrackStudio both supported it. Over the back of the week a couple of FOSS daws got pretty far on implementation. And the wrappers are making real progress in the last few days which could open up the promise of write clap run elsewhere, albeit with at most the feature set of the outer wrapper. A wrapper to a format that doesn’t support polyphonic modulation won’t have gestures to translate.

Similarly the way clap is designed let’s you layer on features. We actually had a bug report this weekend because a dev bootstrapping a host had chosen to not support params at all yet, and surge didn’t like that. But the api made it clear who was at fault and how to fix that.

Nothing new there but thought some color from the front lines in dev land may help.

[sQeetz]

All of them. The danger of Steinberg pulling such a stunt again is very real. You obviously haven't been around last year when this stuff was playing out in realtime and a bunch of devs raised pitchforks.

Indeed I wasn't paying attention

[jamcat]

If those plugins were created from VST2 core then wrapped into other formats, as majority of plugins out there really are

See, I’m really not convinced of that part. VST2 was an interface standard, just as VST3 is. The core DSP should be interface agnostic, inside of an interface-specific framework that handles the I/O. So porting to a different interface standard means building a framework for that standard.

That seems like “the right way” to do it, anyways. And I’m sure the major developers have done it that way from the start.

So this VST2 bandaid approach doesn’t apply to the likes of Waves, Eventide, IK Multimedia, Arturia (who uses JUCE), etc. These companies account for a substantial percentage of the plugins most people are using.

[No_Use]

sadly at the moment only bitwig as a host is supporting it.

MultitrackStudio too.
https://www.kvraudio.com/news/bremmers- ... udio-55123

edit: Already mentioned above by @baconpaul

[EvilDragon]

And I’m sure the major developers have done it that way from the start.

Don't be so sure.

Also, I'm not at all talking about the "DSP core", I'm talking about "plugin interface core". Great majority of developers pick one format as basis (either VST2 or AU) then wrap into other formats. This is where the danger lies in case dev's backbone is VST2. And a LOT of devs chose VST2 as their backbone.

So this BST2 bandaid approach doesn’t apply to the likes of Waves, Eventide, IK Multimedia, Arturia (who uses JUCE), etc. These companies account for a substantial percentage of the plugins most people are using.

Arturia uses JUCE only for the GUI, not for plugin format wrappers, for that they have their own thing. Just one of many examples.

[pdxindy]

Pdxindy - you should really try surge too if you haven’t. From hearing you speak about the uhe synths I bet you will love it

I will... was kinda waiting for the dust to settle as I didn't want to be dealing with nightly builds

[vurt]

sadly at the moment only bitwig as a host is supporting it.

MultitrackStudio too.
https://www.kvraudio.com/news/bremmers- ... udio-55123

ah cool!
still no use to me but its a start!

thanks for the heads up

[10bd01]

However, Apple forced developers to basically stop developing to concentrate in coding to support their new platform, and I didn't see many concerns raised about that. And that for the only benefit of Apple and a bunch of users that ran to buy M1 laptops.

Ok, "stopping development" is exactly the type of situation the people in this thread were concerned about as a potential effect from introducing a new format. Doesn't seem like it's an issue to be concerned about. Not sure what people not raising concerns in the past has to do with people raising concerns now, but sure, let's let what people did in the past determine what we do now.

[sQeetz]

I didn't say it benefits you. I said it benefits me cause I use Bitwig and the Bitwig modulation system is freakin awesome (but previously limited to Bitwig instruments for per voice modulation)! Unlimited per voice modulation in the u-he synths (ACE, Diva and Hive now and RePro and Bazille to follow) was an absurd fantasy, but just became a reality. Today I have been making these slow, gorgeous, textural pads in ACE cause now I can modulate various parameters that cannot be modulated directly in ACE (with a far wider range of modulators) which opens up a new sonic landscape.

awesome! But still a no-go from my standpoint.

[ghettosynth]

I didn't say it benefits you. I said it benefits me cause I use Bitwig and the Bitwig modulation system is freakin awesome (but previously limited to Bitwig instruments for per voice modulation)! Unlimited per voice modulation in the u-he synths (ACE, Diva and Hive now and RePro and Bazille to follow) was an absurd fantasy, but just became a reality. Today I have been making these slow, gorgeous, textural pads in ACE cause now I can modulate various parameters that cannot be modulated directly in ACE (with a far wider range of modulators) which opens up a new sonic landscape.

Something tells me that I'm going to upgrade my 8-track before the week's out.

[sQeetz]

I have Bitwig, but I still refuse to use it until they fix the mouse pointer full screen behaviour on MacOS.
It's ridiculous. Update after update I check if it got fixed... but nope

[jamcat]

So this VST2 bandaid approach doesn’t apply to the likes of Waves, Eventide, IK Multimedia, Arturia (who uses JUCE), etc. These companies account for a substantial percentage of the plugins most people are using.

Arturia uses JUCE only for the GUI, not for plugin format wrappers, for that they have their own thing. Just one of many examples.

Right, they have their own framework, just like the others I mentioned. I mentioned their use of JUCE because they are the only ones of that group who use anything that isn’t completely in-house.

So what incentive do these companies have to port their combined hundreds of essential industry standard plugins to CLAP? Will they ever see CLAP, and if so, how many years will that wait be?

That’s the bottleneck I’m talking about.

[Super Piano Hater 64]

[EDIT: This post was a mistake, as were my other posts that just got deleted. I apologize and I'll stay out of this thread for the time being.]

As Urs has begun to explain it better, it seems like CLAP could present a way for fast development and prototyping for new plugins [...] But the major hurdle that I’ve been trying to discuss, which I’m still seeing, is that there is really no incentive for existing 3rd party plugins to be ported. [...] No one is addressing the substantial investments we’ve already made.

At least half of the discussion of CLAP has been about improvements to existing plugins. You're one of the people who still don't understand how or why. I'll try to explain again.

You mentioned bottlenecks before. Steinberg created one by killing VST2. There is no debating that part, and no room to negotiate the decision. It's a done deal. The grave is dug, the tombstone is chiseled, and half the nails are in the coffin.

The reason it's a bottleneck is that many developers targeted VST2 as an intermediate format. Their plugins are VST2 under the hood, and they use wrappers of some kind to deploy other plugin formats like VST3. Steinberg doesn't want people to do that anymore. It's a major legal hazard for anyone whose VST2 license gets withdrawn — which is supposed to be literally everybody at some vague point in the future.

Thus, developers need a new intermediate format. Many of them are using JUCE, which is only an intermediate format and doesn't exist as a plugin format in its own right. Some others are using VST3. Neither of these is actually a very good replacement for VST2, because from the perspective of a plugin developer, the APIs are very different. (You might still disagree with that assertion, as you have before, but keep in mind that many developers used the basic VST2 plugin interface and not the rest of the SDK. That part saw major fundamental changes between VST2 and VST3.)

CLAP was designed with all this in mind. It is similar enough to VST2 (at the basic plugin interface level) to make it very easy to replace VST2 with CLAP under the hood in an existing codebase, while simultaneously giving developers room to add all kinds of new features when they're ready for them. They can then continue using wrappers to export other formats like AU and VST3. It was designed this way specifically because there are developers who need exactly such a solution. It is the safe path forward for keeping old plugins alive.

Is this starting to make any kind of sense to you?