Introducing CLAP 1.0, open-source audio/MIDI plugins API

After 7 years of work, CLAP 1.0 SDK for audio/MIDI plugins is now available. Bitwig and U-he, both collaborators on the project, issued an official announcement. There are both hosts and plugins available with CLAP support now.

Disclaimer: I covered most of the topics here previously in two write-ups for LWN, “An introduction to Linux audio plugin APIs “ and “The Clever Audio Plugin “. So I might be inadvertently repeating myself.

What is CLAP?

Much like VST, AU, LV2 and others, CLAP is an software development kit for creating audio effects and virtual instruments that work across multiple host applications like digital audio workstations, MIDI sequencers, and audio editors.

While some SDKs are proprietary and have to be licensed (e.g. AAX by Avid), CLAP is open-source (MIT License).

Functionally, CLAP is two steps back and two-three steps forward as compared to e.g. VST3. It’s simple like VST2 but supports a few fancy features like MIDI 2.0 and polyphonic modulation. In many aspects, it’s perfectly comparable to other FLOSS software development kits, VST3 and LV2.

This project has been in the works by Alexandre Bique since 2014, with a few long sabbaticals in between, and got a boost a year ago thanks to U-he’s Urs Heckmann and then support from Bitwig where Alexandre works.

With LV2 and VST3, do we need another plugin API?

It’s a loaded question!

Steinberg rubbed VST plugin developers the wrong way with how they have been sunsetting VST2 — by making it virtually impossible to build new VST2 plugins and then planning to remove VST2 support from their hosts (Cubase, Nuendo) altogether.

The VST3 rollout has been problematic as well. One notable example is how they introduced a way to migrate VST2 plugins to VST3 while maintaining IDs so that old sessions would load with all plugins and their automation. In a nutshell, they didn’t think it through and did not tell anybody about it. So plugins' developers changed IDs, and now users have to pay with their time to partially redo old sessions. All this could have been avoided with better developer relations.

Actually, Steinberg has been upsetting plugin developers for so long that LV2 and CLAP aren’t even the first attempts at an open-source replacement for VST. GMPI was an earlier project from 2003, with people from a larger music industry involved (think Cakewalk/Sonar).

With LV2, there’s a feeling that it failed to grab mainstream attention for various reasons, and now it’s too late. While covering the topic extensively in my write-up for LWN, I spoke to multiple plugin developers on and off the record, and I’ve consistently heard this: “The learning curve was really steep, I wish it’d be a lot simpler to get started, but once I got the hang of it, it was okay”.

Developers of proprietary plugins will happily tell you they either never heard of LV2 (probably true) or tried making a port and found it too cumbersome (also probably true), so they wouldn’t bother again. Others would tell you they didn’t like some of the design decisions and failed to get their points across to LV2 maintainers.

And then, if you intend to make your plugins available with multiple APIs support from the same code base, that usually means a framework like JUCE, and LV2 isn’t very popular with framework developers presently.

Finally, while there are over a thousand existing LV2 plugins, if you are coming from a larger community of musicians, you probably only heard a handful of names like Vital and Pianoteq where LV2 is an option.

So there have been technical, as well as cultural concerns with regards to VST3 and LV2, and Alexandre acted on them.

Is anyone important supporting CLAP?

Yes, there are companies and open-source projects that already provide CLAP builds of plugins or releases of hosts with CLAP support. Proprietary: Bitwig, U-He, MultitrackStudio. Free/libre: Surge XT and Odin 2, both software synths have a growing following.

The Surge team in particular appear to be the center of all CLAP activity in the FLOSS community. They are utterly in love with CLAP, and if you are looking into writing a CLAP plugin, the ‘clap-chatter’ room on their Discord server is the first place you should go to with your questions.

Quite a few companies you might hope to be on board with CLAP haven’t yet mentioned whether they are evaluating the API. Ableton and NI are some of the big names there. Steinberg and Apple too, for obvious reasons.

There’s also a long list of companies and open-source projects that are said to be evaluating CLAP. It’s in the official announcement too. You probably also know some of those names: Arturia, Avid, Cockos, Presonus.

The most surprising company to be listed there is, of course, Avid. The very same Avid that limits its own host applications to their own APIs (RTAS and AAX). Personally, I’m firmly in the “I believe it when I see it” camp here, but I’ve seen stranger things happen.

That ’evaluation’ list comes with an easter egg, because in all actuality some of the developers already have working CLAP ports of their products, they aren’t just ready to publicly announce them yet.

And then there are projects that don’t mention CLAP builds anywhere visible yet, but do have test builds. Dexed would be one of them, with a CLAP build available on GitHub actions recently.

How will CLAP developers avoid becoming the next Steinberg?

Ultimately, the problem with VST3 is Steinberg’s culture of making unpopular decisions in a non-transparent manner. So it makes sense to ask, how design decisions will be made going forward for CLAP. This is what the announcement says on the matter:

CLAP 1.0 is the result of a multi-year project initiated by u-he and Bitwig, with design and implementation contributions by a group of commercial and open source audio developers from across our industry. As we proceed beyond the initial set of extensions, we are committed to establishing a transparent process to govern the standard which allows participation from the entire audio software community. We welcome participation from the development community today, and we will share details of these processes and governing models over the second half of 2022.

How can you see it in action?

So far, the only free/libre host where CLAP support might show up soon is Qtractor, as per this discussion. Which means that, right now, you need a proprietary host and either proprietary (U-he family) or free/libre plugins (Surge XT, Monique, Odin 2, Dexed are the usable ones).

Ardour and Zrythm developers are likely to accept patches for CLAP support. Both projects are currently more or less wrapping up development of respective major updates, so bug fixing and polishing is their top priority. I don’t think it’s sensible to expect them to drop everything and start working on CLAP support right now.

If CLAP is successful, is LV2 done for?

Everyone is so damn polite about this, it’s almost boring. Just kidding! But it’s a real question: what happens if/when CLAP becomes a mainstream plugin API?

Here is something I’d like you to consider. While there are amazing LV2 plugins implemented with custom toolkits (LSP series, x42 series, and more), the free/libre plugins that get everyone’s attention tend to be written with this or that framework, and often enough it’s JUCE. Think Surge XT and its extended family (Monique, Shortcircuit XT etc.), Vital, Odin 2, Dexed, Ob-xd. Or you could look at anything written with DPF or iPlug2.

Well, the thing about frameworks is that they take your code base and spit out binary plugins for multiple APIs. So as long as you rely on a framework that — through support for VST3, AAX, AU, LV2, and CLAP — gives you a decent coverage of hosts, why would you care?

CLAP developers created a JUCE extension to simplify making CLAP binaries. LV2 official support is finally coming to JUCE7 probably later this year. As far as I’m concerned, there is no reason to fight. One way or another, they will coexist.

However, if LV2 developers care about wider support in proprietary host applications (which they don’t have to), they’d need to figure out the way to make LV2 interesting for that demographic. And it’s one hell of a challenge.

Finally, if you were to think really far ahead, you’d expect technology replacing both LV2, VST3, and CLAP with something newer every 10-15 years. That’s how software works. As opposed to something like a 1982 Boss OC-2 pedal that is a gift that keeps on giving.

What’s next for CLAP?

Judging by discussions in ‘clap-chatter’, you should expect more CLAP plugin releases in the coming months, not all of them proprietary!