CLAP: new plugin standard from u-he and Bitwig

[Guy Rowland]

Bitwig and u-he have teamed up to create a new open source plugin standard. As I understand it, it's a protocol that exists between the plugin itself (of whatever type) and the host. Here is what they say the point is (it has my interest for the first point alone - though it doesn't look like it can actually add multicore support to a single core plugin)

Better Performance From Modern CPUs
Developed with modern CPUs in mind, CLAP takes multi-thread management to a new level, with a clear and efficient allocation of roles between plug-in and host. Specifically, CLAP allows collaborative multicore support between plug-in and host through a so-called "thread-pool", also allowing hosts to manage CPU-threading for plug-ins that provide their own multicore support. Preliminary tests show significant performance gains compared with current solutions.

Better and Faster Organization
CLAP hosts can read plug-in metadata and help organize your plug-ins. As CLAP hosts can retrieve information from plug-ins without having to wait for them to initialize, plug-in scans can be much faster.
Furthermore, we're currently finalizing an extension which lets plug-ins tell the host which files they need (e.g. samples or wavetables), and the host can consolidate those in the project file. That means you'll never lose a sample while transferring a project between systems!

Better Modulation
The CLAP standard promotes new ways to create music with automation, modulation, and expressions. Here are a few examples:

CLAP supports per-note automation and modulation (in accordance with the recent MIDI 2.0 specifications).
Going one step further, CLAP's parameter modulation concept allows for temporary parameter offsets. Parameter modulation is non-destructive, so as soon as the modulation has finished, the target parameter will return to its original state.
CLAP makes it possible for polyphonic plug-ins to have their per-voice parameters modulated for individual notes ("MPE on steroids").
With this new standard we aim to inspire host developers to add exciting new features to their products. Initial implementations by Bitwig, u-he and the Surge project demonstrate just a few of the possibilities.

Not many supporters right at launch but they list a promising number who are "already evaluating CLAP for their host and plug-in software", including Arturia, Avid, Cockos, FabFilter, Presonus and Plogue.

https://u-he.com/community/clap/

[EvilDragon]

though it doesn't look like it can actually add multicore support to a single core plugin

This is just not possible for a wide variety of reasons.


Anyways, exciting times ahead!

[Geoff Grace]

The new standard sounds very promising, both in terms of who it’s from and what it can do.

As for the CLAP name, it has associations that are positive (applause) and negative (gonorrhea); but I guess we’ll get used to it.

Best,

Geoff

[EvilDragon]

https://urs.silvrback.com/clap

[Guy Rowland]

Quoting Mario from elsewhere, a useful summary of how exactly this host will work, as I didn’t realise there will be .clap plugins:

If host supports .clap you just load it outright. Like any other plugin type. But it is likely that in the future you could be loading, say, a VST2 or VST3 or AU, but it's actually a CLAP plugin served to you through a wrapper that you don't see in any way. It's completely transparent.

All sounds lovely. I wonder if Steinberg will feel slighted and drag their feet in supporting it.

As for the CLAP name, it has associations that are positive (applause) and negative (gonorrhea); but I guess we’ll get used to it.

That’s what my doctor told me too.

[Geoff Grace]

LOL, Guy!

The jokes are inevitable. Someone on another site wrote, "very interested to see if this catches on and gets spread."

Best,

Geoff

[EvilDragon]

how exactly this host will work

It's not a host. CLAP is a protocol describing how hosts and plugins should behave. Just like VST, AU, AAX. The trick is in implementation differences. For example:

VST is a C++ API. This means it makes it much more difficult to write a VST plugin using a language that is not C++. It's possible, but it's way trickier to make bindings to other languages. Even worse with VST3.

CLAP is a C API, which makes it super simple to interop with practically any other programming languages (bindings with Rust already exist, with more to come). So, this is a net positive for plugin developers, it's not a necessity to deal with all the C++ pitfalls (there are many).


But really the most important thing here is the unencumbered license. Steinberg's governance over VST was not exactly admirable (especially the way they dealt with retiring VST2), plus the license is quite loaded and basically Steinberg is free to pull the rug under everyone else who signs it, whenever they feel like it. They even attempted to terminate existing, valid and active VST2 contracts by signing an updated VST3 license contract, but this just pissed developers off even more, so they backtracked relatively swiftly. But this just showed they could flex that sort of stuff at the flick of a wrist.

Many plugins you use these days are based on only one plugin format (usually VST2 or AU), which is then wrapped into other formats. You don't know about this, you don't feel it in performance. But it's there. So imagine now, you're a plugin developer, and you have your whole product range based off of VST2, and then Steiny attempts to do stuff like what I just mentioned above. How'd that make you feel?


So the main thing here is the license is very open and there's no chance of nefarious stuff like this ever happening. Clean license, piece of mind for the future of plugin development.

[tack]

But really the most important thing here is the unencumbered license. Steinberg's governance over VST was not exactly admirable (especially the way they dealt with retiring VST2), plus the license is quite loaded and basically Steinberg is free to pull the rug under everyone else who signs it, whenever they feel like it.

This point is the most significant aspect to CLAP for me. I just hope it succeeds in displacing VST.

I'm not a plugin author so I wasn't paying attention to why it was that LV2 never caught on, but I'm hoping there were good technical or legal reasons that are addressed by CLAP.

[Geoff Grace]

For any who are eager for a test drive, the free synth, Surge XT, has a beta release with CLAP support:

https://surge-synthesizer.github.io

Best,

Geoff

[Guy Rowland]

Thanks Mario - the websites need your explanations!

The thing I'm most concerned about is Steinberg stubbornly refusing to play ball. Avid's inclusion on the list is hugely significant - here's hoping it takes off rapidly. Already Cubase is one of the worst performing DAWs, that gap will only increase if it doesn't also get the CLAP.

Dammit its so hard not to make jokes.

[Guy Rowland]

Just posting this from KVR - u-he's Urs is providing some fascinating commentary on this. There, I'd raised the issue of NI's lack of support so far - surprising to me given u-he and NI have a strong working relationship.

Well, there were very productive talks with NI in the beginning, but they declined support for CLAP early on due to their plans to move to VST3. Judging by the pace of that transition, I would really like to talk to this engineer again who raised that point.

It surprised me then and it surprises me now. Because obviously NKS - a major asset of NI - is tied to a deprecated format and obviously the demise of that format has therefore cost NI an amount of money and shareholder value that is certainly unprecedented in the industry. It seems obvious to me that no other plug-in manufacturer has lost more due to this particular decision of another company.

We reached out back then because we were sure that NI would be working on their own format to proceed, and thus it would make sense to collaborate. Apparently they didn't, but still they wouldn't - yet, I sincerely hope they eventually will. CLAP would make so much sense, it's beyond me why they're not on board yet.

[EvilDragon]

Yeah NI is just up to their necks in technical debt. So they prefer to focus on first resolving VST3 support across their whole (quite sizable) portfolio, and then HiDPI. Only then it seems logical to take on additional targets.

[FriFlo]

It is intriguing to see software developer with the energy to push some things forward! However, the sceptic in me says this will take ages until we media composers are going to be able to enjoy something like that. The fact that Kontakt just recently migrated to VST3 says everything about the tempo to expect.

For years (rather decades almost) now, there is a deep gap between what is technically possible with the hardware and software available and what the user is able to actually use without having to become a programmer himself. On the one side, we have multi-dimensional controllers like the seaboard or osmose, iPads with touch controller software to build your custom controller as cheap as never before possible and a 10 year-old can build his custom midi controller with the help of Arduino. Yet, all the software development has basically slept for more than a decade to integrate all of that in a meaningful way. In almost all cases, they created approaches that were not used any hence abandoned like Cubase with note expression. Even Expression Maps, something that was a good idea, has not been developed further, although it should have been obvious to just integrate it with a tablet app ...

You might counter, that most users are just not interested and happy with their 2-octave plastic keys with barely velocity! But the job of an inventive company is to show it is customers why it is desirable what they have to offer. By just serving people what they supposedly want, we wouldn't have smartphones or even computers today!