CLAP... thoughts?

[mystran]

It says on U-he page that some beta version of Bitwig already has CLAP support? So my question is, has anyone tested it or done benchmarks yet?

It's now in the release version (Bitwig 4.3) as well.

[PieBerger]

It says on U-he page that some beta version of Bitwig already has CLAP support? So my question is, has anyone tested it or done benchmarks yet?

With multicore enabled I can run 25% more instances of the same 12 voice Diva patch (4 voice stack, 3 note chord) compared to the VST3

[SiliconDeath]

It says on U-he page that some beta version of Bitwig already has CLAP support? So my question is, has anyone tested it or done benchmarks yet?

With multicore enabled I can run 25% more instances of the same 12 voice Diva patch (4 voice stack, 3 note chord) compared to the VST3

What about performance boost on single track? I think the multi track performance isn't the biggest problem, but what most often has been the problem (at least for me) is when a single track starts to become too heavy (either from too much processing, or when pushing virtual instrument "too hard", usually combination of poly unison and "above medium" release times).

[rafa1981]

It says on U-he page that some beta version of Bitwig already has CLAP support? So my question is, has anyone tested it or done benchmarks yet?

With multicore enabled I can run 25% more instances of the same 12 voice Diva patch (4 voice stack, 3 note chord) compared to the VST3

What about performance boost on single track? I think the multi track performance isn't the biggest problem, but what most often has been the problem (at least for me) is when a single track starts to become too heavy (either from too much processing, or when pushing virtual instrument "too hard", usually combination of poly unison and "above medium" release times).

Well, CLAP helps the host doing smarter decisions with regards to thread/core scheduling/utilization, but it doesn't make the DSP itself to run faster. Single track "benchmarks" should stay the same. On a real project the limiting track may or may not be offloaded, lots of variables are in play.

[teilo]

[deleted]

[teilo]

[deleted]

[PieBerger]

Urs of u-he gave the primary reason: "The main reason we (u-he, others may have other reasons) try to bring forward a new plug-in standard is very simple: It's liberally licensed. No one needs to pay fees, hire lawyers or go through vetting process. No need to sign weird contracts or NDAs that may turn into future risks of investment."

And yet no one—including u-he—is going to drop VST, AU, or AAX support. So they'll all still be doing all of those things. Like I said, it's all just politics.

the point is, developer's codebase will no longer be held to ransom by Steinberg-Yamaha. Sure developers will continue to support existing plugin formats, with a key difference that the source code is completely independent of influence from any third-party. If securing an independent future, free from the shackles of an unhelpful, unfriendly, lazy/disinterested third party, is just "playing politics" then let the games begin.

[Urs]

The point for us is that we can use CLAP as our internal format. There are several wrappers in the works that take a CLAP plug-in and make a VST3 from it.

This will improve our internal development process as we won't need to care about other formats "all alone" anymore. The community will care for it in a collaborative approach and we can focus on our own development.

And as I always said, it doesn't matter if Cubase gets CLAP support or not. Here's some work in progress - it needs fine tuning, but it nicely shows a CLAP-only plug-in running in a VST-only host:

CLAPasVST3.png

[SiliconDeath]

Urs of u-he gave the primary reason: "The main reason we (u-he, others may have other reasons) try to bring forward a new plug-in standard is very simple: It's liberally licensed. No one needs to pay fees, hire lawyers or go through vetting process. No need to sign weird contracts or NDAs that may turn into future risks of investment."

And yet no one—including u-he—is going to drop VST, AU, or AAX support. So they'll all still be doing all of those things. Like I said, it's all just politics.

If CLAP starts getting wind, I wouldn't be surprised if newer plugins 2-3 years from now start dropping support for VST2 and VST3. Part of the problem of VST2/VST3 is that you have to install both for some plugins, so it's not really worth the hassle/drive space wasted. Just to eliminate that uncertainty whether you need vst3 version of certain plugin, or vst2 for another plugin, if CLAP can get rid of that hassle then it will be great.

[Urs]

If CLAP starts getting wind, I wouldn't be surprised if newer plugins 2-3 years from now start dropping support for VST2 and VST3. Part of the problem of VST2/VST3 is that you have to install both for some plugins, so it's not really worth the hassle/drive space wasted. Just to eliminate that uncertainty whether you need vst3 version of certain plugin, or vst2 for another plugin, if CLAP can get rid of that hassle then it will be great.

Or, they install a 50kB CLAP-as-VST2 and a 50kB CLAP-as-VST3 which load the 10MB CLAP.

[PieBerger]

It says on U-he page that some beta version of Bitwig already has CLAP support? So my question is, has anyone tested it or done benchmarks yet?

With multicore enabled I can run 25% more instances of the same 12 voice Diva patch (4 voice stack, 3 note chord) compared to the VST3

What about performance boost on single track? I think the multi track performance isn't the biggest problem, but what most often has been the problem (at least for me) is when a single track starts to become too heavy (either from too much processing, or when pushing virtual instrument "too hard", usually combination of poly unison and "above medium" release times).

I didn't try pushing a single track, that can be next on the list of things to try. I'll report back if I remember to do it!

[jules99]

I did some benchmarks for a review of Bitwig 4.3 with Diva as VST3 and Diva as CLAP. Test machine was an M1 Mac Mini base model with 8GB RAM and 512 GB SSD.

A loop with four chords and four voices each was created playing the init preset of Diva. Both CLAP and VST3 in single core mode were equal, maxing out at 19 tracks before CPU overload.

When activating multi-core in Diva, I could only do four tracks of Diva VST3. But 20 tracks of CLAP before overload.

Now this is a very simple mac, the base model of M1 is fast, but with M1 Pro, Max or Ultra this would have probably been a much higher difference. I'd love to see the same test in a Windows environment with both Intel and AMD CPUs.

[Urs]

Yeah, on M1 it's particularly difficult for a plug-in to do its own multi threading. I think we simply end up processing a few voices on the energy efficient cores, and thus taking more CPU than we should.

There'll be a whole paper on why we did this in CLAP and what the expected advantages are.

[moss]

Yeah, on M1 it's particularly difficult for a plug-in to do its own multi threading. I think we simply end up processing a few voices on the energy efficient cores, and thus taking more CPU than we should.

There'll be a whole paper on why we did this in CLAP and what the expected advantages are.

Is this publicly available?

[Urs]

Yeah, on M1 it's particularly difficult for a plug-in to do its own multi threading. I think we simply end up processing a few voices on the energy efficient cores, and thus taking more CPU than we should.

There'll be a whole paper on why we did this in CLAP and what the expected advantages are.

Is this publicly available?

Soon I hope. It's part of the official CLAP website project which I'm overseeing. Nothing fancy, just something a bit deeper than the Github readme.