CLAP... thoughts?

[EvilDragon]

See ya in a year or less where we say "we told you so".

[dayjob]

But few plugin developers are going to invest the substantial resources in developing and supporting another platform on top of all of the others they already do, if they’re not missing out on market share by not.

we'll see. [shrug]

[jamcat]

See ya in a year or less where we say "we told you so".

Well best of luck on that, truly. If all of the plugins I already bought are all updated with CLAP support, and so is my host, then maybe I would swap out all my VST3 plugins for the CLAP versions in all of my songs. But then again, what advantage would that give me as a user? Sounds like a lot of work on my end just to get the same results I'm already getting right now. If nothing's really broken on my end, why would I need to fix it?

Now, if I really saw my CPU overhead drop considerably because of better mutithread handling, then that would be something concrete, and I certainly wouldn't argue with that. I'm just skeptical of how much improvement you really see in a real-world situation, since (on M1 Mac) CPU core delegation is already quite efficient with VST3, and it's usually specific single thread operations that eat up CPU anyways. Does it really make any real difference when it actually matters? I'd like to see some benchmarks on that.

But regardless, I think "a year or less" is unrealistically optimistic. I think it will be more than that before I even see my T-RackS plugins native on M1.

[EvilDragon]

Well, from early tests, CLAP Diva is already way more efficient than VST3 Diva on M1 as far as multicore performance is concerned...

[jamcat]

That's pretty vague, though.
On the same system, in the same host with the same audio buffer size and the same samplerate, how many CLAP instances vs. VST instances of the same plugins with the same settings processing the same audio can you run before the CPU starts choking?

Also, how many plugins can actually take advantage of that? Most plugins' audio processing is single-threaded by necessity.

[melomood]

Is it wrong to think any standard that is less of a pita for the developers could also benefit customers of the final product? Dare I say possibly leading to more experimentation of design?

[mystran]

Now, if I really saw my CPU overhead drop considerably because of better mutithread handling, then that would be something concrete, and I certainly wouldn't argue with that. I'm skeptical of how much improvement you really see in a real-world situation, since (on M1 Mac) CPU core delegation is already quite efficient with VST3, and it's usually specific single thread operations that eat up CPU anyways.

The main benefit here comes from allowing the host to better coordinate threading and getting rid of the problematic competition between host threads and plugin private threads. Such competition can result in higher "CPU load" in the audio sense (ie. how much wallclock time was left over), even if the total number of CPU cycles spent doing something stayed roughly the same. In practice it might also reduce the number of CPU cycles needed, but I'd guess that's probably not as significant.

The improved coordination and reduced competition here can absolutely translate to better performance even when the bottleneck is single-threaded if there are other multi-threaded plugins involved, because those multi-threaded plugins are less likely to slow the true bottleneck down. This particular feature of CLAP is something that really should have been in every plugin API some 10 years ago, because it's absolutely a real meaningful improvement over the existing situation.

[jamcat]

Is it wrong to think any standard that is less of a pita for the developers could also benefit customers of the final product? Dare I say possibly leading to more experimentation of design?

Yes, it is wrong. Because they're not replacing said PITA standards with a less PITA standard. They're just adding yet another standard on top of all the others that they already have to support. If one standard is a 4 on the PITA scale, and you add a new standard that is a 2 on the PITA scale, your net PITA is now 6.

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

[melomood]

I meant the pita of the licensing,nda's,dealing with Steinberg etc

[zvenx]

Are you sure developers creating third party vst3s have to sign nda's with steinberg? Or are you just repeating something you heard implied?

Unless you are developing or testing some yet to be announced product for Steinberg, it would be strange for them to require you sign an nda when their vst3 sdk is publicly available.


Rsp

[MirkoVanHauten]

Is it wrong to think any standard that is less of a pita for the developers could also benefit customers of the final product? Dare I say possibly leading to more experimentation of design?

Yes, it is wrong. Because they're not replacing said PITA standards with a less PITA standard. They're just adding yet another standard on top of all the others that they already have to support. If one standard is a 4 on the PITA scale, and you add a new standard that is a 2 on the PITA scale, your net PITA is now 6.

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

If you'd have read what the actual devs involved wrote, you'd already have understood that CLAP can easily be used as an intermediate format. Only code CLAP, get all other formats for free. This is getting rid of PITA which you as a customer might not see because you get all what you got before + 1 more... ...which then eventually can be reduced one by one to only distribute CLAP at some point when it can be used across DAWs.

[Super Piano Hater 64]

Is it wrong to think any standard that is less of a pita for the developers could also benefit customers of the final product? Dare I say possibly leading to more experimentation of design?

Yes, it is wrong. Because they're not replacing said PITA standards with a less PITA standard. They're just adding yet another standard on top of all the others that they already have to support. If one standard is a 4 on the PITA scale, and you add a new standard that is a 2 on the PITA scale, your net PITA is now 6.

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

It has been explained to you multiple times why this is not the case.

You like to say your time is precious. Please treat it that way. Go make some music or something.

[Lucastyle]

My toughts are that this is awesome and I can’t believe some people are arguing against it haha

I hope ableton jumps in soon

Congrats to u-he and the rest of the developer for pushing innovation

[jamcat]

Is it wrong to think any standard that is less of a pita for the developers could also benefit customers of the final product? Dare I say possibly leading to more experimentation of design?

Yes, it is wrong. Because they're not replacing said PITA standards with a less PITA standard. They're just adding yet another standard on top of all the others that they already have to support. If one standard is a 4 on the PITA scale, and you add a new standard that is a 2 on the PITA scale, your net PITA is now 6.

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

If you'd have read what the actual devs involved wrote, you'd already have understood that CLAP can easily be used as an intermediate format. Only code CLAP, get all other formats for free. This is getting rid of PITA which you as a customer might not see because you get all what you got before + 1 more... ...which then eventually can be reduced one by one to only distribute CLAP at some point when it can be used across DAWs.

So far that doesn't exist, but it would be great if it does one day. At least from the development side of things.

Unfortunately, in the real world, customer support accounts for the largest single expense for a software company, and increasing the number of supported platforms necessarily means increasing the cost of support.

If your new platform you're supporting doesn't actually open up a new, previously inaccessible market segment, then it doesn't increase your customer base. So congratulations, now you're spending more on tech support but not bringing in new revenues. Those new costs have to be reallocated from somewhere else, most likely development and testing.

Users don't benefit from that. They suffer as a result.

[melomood]

Is it wrong to think any standard that is less of a pita for the developers could also benefit customers of the final product? Dare I say possibly leading to more experimentation of design?

Yes, it is wrong. Because they're not replacing said PITA standards with a less PITA standard. They're just adding yet another standard on top of all the others that they already have to support. If one standard is a 4 on the PITA scale, and you add a new standard that is a 2 on the PITA scale, your net PITA is now 6.

that means a 50% increase in resource allocation, which translates to fewer new plugins, more bugs, and longer wait times between updates for your preferred standard, whatever it may be.

If you'd have read what the actual devs involved wrote, you'd already have understood that CLAP can easily be used as an intermediate format. Only code CLAP, get all other formats for free. This is getting rid of PITA which you as a customer might not see because you get all what you got before + 1 more... ...which then eventually can be reduced one by one to only distribute CLAP at some point when it can be used across DAWs.

That plus I had been reading some posts about Steinberg being a bit slow on the implementation of features in vst3 and announcing dropping support for the vst2 format some devs were still preferring etc
Not having to deal with those hassles on the dev side and how some features in CLAP as well,could ultimately benefit customers of the final products in the end