Clap Plugin Format

[] Peter:H []

double post

[Tj Shredder]

Successfully installed Surge XT nighly as Clap on OSX Mojave and Bitwig final 4.2. It loads fine, but MPE is broken. The VST3 works fine with MPE... Does that also happen on Windows? I wonder if its a Surge or a Bitwig bug...

[baconpaul]

Successfully installed Surge XT nighly as Clap on OSX Mojave and Bitwig final 4.2. It loads fine, but MPE is broken. The VST3 works fine with MPE... Does that also happen on Windows? I wonder if its a Surge or a Bitwig bug...

It’s probably somewhere between - how is it broken?

Actively working on surge clap now. It won’t be as robust as the vst3 yet since al the endpoints are still moving and clap versions are still moving around too. But as with all things surge we fix what we know about! So any info welcome.

And thanks for trying. Folks like you who take time to drive the nightly versions is how we get good production releases!

[ThomasHelzle]

Successfully installed Surge XT nighly as Clap on OSX Mojave and Bitwig final 4.2. It loads fine, but MPE is broken. The VST3 works fine with MPE... Does that also happen on Windows? I wonder if its a Surge or a Bitwig bug...

It’s probably somewhere between - how is it broken?

Actively working on surge clap now. It won’t be as robust as the vst3 yet since al the endpoints are still moving and clap versions are still moving around too. But as with all things surge we fix what we know about! So any info welcome.

And thanks for trying. Folks like you who take time to drive the nightly versions is how we get good production releases!

Yeah, same here.
Tried with a seaboard block.
Both versions using the same preset, Roger Linn, LS Z-Filter, Y-Pulsewidth.
In the VST3, all three axes are working as expected.
in the Clap, none of them do anything.
MPE is activated for the device in Bitwig and inside of Surge.
This is nightly 7394f52.
Will try with the latest now.

Edit: Same issue with the latest from today.
The sound is very low volume and does not react at all to the axes.

Cheers,

Tom

[Tj Shredder]

Successfully installed Surge XT nighly as Clap on OSX Mojave and Bitwig final 4.2. It loads fine, but MPE is broken. The VST3 works fine with MPE... Does that also happen on Windows? I wonder if its a Surge or a Bitwig bug...

It’s probably somewhere between - how is it broken?

First thing I do, is load a sound and bend it polyphonically. Well, it doesn’t bend at all. It might be a confusion between expressions and the actual pitch bend. It could be a Bitwig issue as well… We had that in the past all the time. Bitwig still translates from Midi to its internal representation and back to Midi. (Instead of keeping both…) If Clap/Surge would seamless support Midi 2.0, it could work out easier. Though the DAW resolution is higher than Midi 2.0, its surely more than good enough (compared to Midi 1.0…)

[baconpaul]

Ok I’ll add it to my list for the week. I hadn’t tried my linnstrument with it yet but will.

In theory since mpe is midi 1 I should get everything the same but theory and practice ….

Appreciate the report

[Tj Shredder]

I just played the Clap version with the generic script instead of the LinnStrument script. There MPE works! That means, as the LinnStrument script translates pitch bend to expression and doesn't pass Pitch Bend anymore, it is the expression which isn't interpreted. I guess that Bitwig assumes that expressions are listened to in a Clap plugin, it does not translate expressions back to Midi...
It does make sense in a way or how should per voice modulation function elsewise? On the other hand, the MPE knob should still create Midi (2.0) events. When MPE isn't checked, expressions should still work...

[baconpaul]

Ahh I am midway through implementing expressions (including adding them to the mod grid as distinct sources) and am working with Alex on some interpretation issues. If you run with transparent midi 1 it should work but if you swap to expressions yeah the nightly won’t. But as I work through expression support this week will need help.

If you happen to have a bitwig project which is set up the “wrong” way (eg doesn’t work) and you could share it that’d be handy. Pm me here or on our discord or on GitHub if willing?

And again appreciate the testing. This isn’t a small project and these early steps are really important

[Tj Shredder]

Well, the project isn’t more than feeding my LinnStrument to Surge XT with all MPE knobs checked… And the Bitwig LinnStrument script of course…

[baconpaul]

Gotcha. Well I will have to learn how to use the bitwig linnstrument script!

[Tj Shredder]

Well, just assign it to the LinnStrument Midi port in the Controller settings…

[Enkerli]

Late to the party. First heard about the Clap format from a post about voice stacking Surge in BWS 4.3b2 (or b1?), some weeks ago.
Now, back from a trip, noticing that Robbert’s plugins are available in Clap format (unfortunately, not native on Apple Silicon).

Promising looking... I am especially interested in its ability to do polyphonic modulation/automation. It means the per voice modulation that currently only works with Bitwig instruments will work with u-he plugins too (CLAP version)

Hmmm... something that VST3 has been doing for 13 years now. Why developers have not caught up is a big mystery to me. The instruments that have fully embraced VST3 have polyphonic pitch bend, pan, filter etc etc.

Do we really need another format to give us that?
Just my two cents...

Also puzzled by the lack of adoption for VST3 features, not to mention the fact that some plugins are only available in VST2. And, as is discussed in several forum threads, Steinberg has fully deprecated VST2.

As for really needing another format, it sounds like it’s a combination of factors. There’s a sociological side to the wellknown Tanenbaum quote and #xkcd927. How do people adopt innovations? It’s a complex process, not just a complicated one.
With u-he and others getting in the fray, putting some efforts behind an unencumbered format, it’s possible that we might avoid the problems plaguing VST and AU adoption. No idea what the odds are (again, it’s a complex phenomenon). As long as the efforts don’t detract from other work at Bitwig GmbH, it’s likely to be worth it.

Something which might help a lot is if we do thorough testing as BWS users. With all sorts of use cases, including edge cases and even corner cases. We’re not yet much of a user community (our “sense of belonging” isn’t very strong). Still, we might be able to rally around certain things, including an approach to quick experimentation.

[pdxindy]

Also puzzled by the lack of adoption for VST3 features, not to mention the fact that some plugins are only available in VST2. And, as is discussed in several forum threads, Steinberg has fully deprecated VST2.

VST3 has been a disaster. Steinberg does not care about supporting an industry standard, only what advances their own business interests. They of course are free to do that, but I would not want to depend on them as a developer.

U-he will be releasing public betas of ACE and Hive in the next 2-3 weeks which support CLAP and per voice modulation in Bitwig. Their other synths will follow. I only need a handful of plugin developers to support CLAP and I can avoid any use of VST3 versions... uninstall them even.

[Urs]

I believe features like NoteExpressions and time stamped parameter changes have not been adopted widely because so many people still have VST2 at the center of their codebase. Nobody could replace it with anything else yet because of the work involved binding that "anything else" to the other standards they want to support - it may simply be too much of an effort.

But CLAP can do that. It'll be easy as pie to move from a VST2 codebase to a CLAP codebase. There's even sample code to show how to connect to VSTGUI from CLAP, for people who still use it.

So I think if people move to CLAP, they can gradually add support for features that were out of reach before.

#---

As for "how can they guarantee stability?" - well there's no guarantee of stability. If a plug-in or host crashes, it crashes. But there is a whole group of crashes that are very common and that are related to threading. This has been taken great care of in CLAP so that those crashes may indeed largely be history. Furthermore CLAP has a communication protocol between host and plug-in to notify each other of bad behaviour. It will finally be possible to send a host developer a plug-in and let them look at the log of their own host to find the culprit, and vice versa.

Funny enough, I expect "cleaning up your threads" to be the hardest part of porting a plug-in to CLAP. On the positive side, once these threading issues are cleaned up, these plug-ins will also be more stable in other formats.

Of course, freshly ported plug-ins and hosts will always crash a bit more often. That's natural, but after a learning period and transition time I firmly believe that CLAP will make plug-ins and hosts more stable.

[ReleaseCandidate]

Urs, just be frank and tell everybody that the main reason of CLAP is to have an excuse to procrastinate Zebra 3 for at least another 3 years