Two and a half years ago, LWN posted my introduction to CLAP, a new MIT-licensed API for audio and MIDI plugin developers. The response to CLAP was mixed: some users and developers welcomed the new API, but some expressed skepticism. Let’s take a look at the evolution of the project and its adoption by developers of digital audio workstations and plugins alike.
CLAP in a nutshell
The API was designed by Alexandre Bique (Bitwig) with support from the u-he team in response to Steinberg’s decision-making on VST, arguably the most popular plugin API on multiple platforms. You can read the details in the original post on LWN or in a post here on Libre Arts, but the short version is this. Steinberg was aggressively phasing out aging VST2 in favor of VST3 but wasn’t providing a clear path for porting existing plugins while making somewhat controversial design decisions that required major rearchitecting of MIDI plugin code.
The dissatisfaction with Steinberg and VST is hardly a new fad. People have tried to dethrone VST for years with open-source projects like GMPI and LV2. Of those, only LV2 gained some popularity, and even that — mostly among developers of free/libre software and on Linux. LV2 itself had a mixed response from developers. Some developers loved it, others found it challenging to get started with.
CLAP was designed to be both easy to adopt and extensible. For developers of both plugins and host applications (e.g., digital audio workstations), there’s only one header file to worry about. Depending on what your plugin or host is capable of, you can choose to implement extra features that are available, such as either stable or draft extensions.
How the API has evolved
A large part of the development since the release of v1.0 was about cleaning up and simplifying the original design of the API, as well as extending it further.
When CLAP v1.0 was released in June 2022, the API arrived with 12 extensions with draft status, including MIDI mapping, support for ambisonic and surround sound, transport control, loading presets, support for arbitrary tuning, support for CV ports (for use in modular/eurorack setups), etc.
Many of these extensions have been stabilized, but more have been created and are still in draft. Here are a couple of examples:
- extensible audio ports where a host can add new audio ports to the plugin,
- better undo support where the undo history in the plugin is merged with the one in the host, so that you could Ctrl+Z safely knowing that whatever you did in either host or plugin will be undone.
Some draft extensions have been removed entirely because either the interface wasn’t satisfying or better solutions presented themselves.
Some of the other notable additions to the API are Preset Discovery, Parameter Indication, and Remote Controls.
Preset Discovery deals with where plugin presets are located, what plugins they apply to, etc. The idea is that users should be able to browse presets from one central location and choose them based on their name rather than choosing a plugin and then selecting a preset. This is convenient when you use, e.g., different EQs in different scenarios and want “that specific preset” rather than “that specific plugin that probably has a preset for this particular problem”.
It will be interesting to see how much adoption this gets. While other APIs provide a general uniform way to list presets for a particular plugin, in reality, few developers choose to use this API and implement preset browsing in their unique way. One reason for that is that some popular digital audio workstations don’t even have a UI for displaying factory presets of 3rd-party plugins. Another reason is that, especially for virtual synths, hosts would have to be able to render categories of presets (think pads, bass, leads, fx, etc.), and they barely manage flat lists. What CLAP does here is a step even further than submitting presets to a host. So, we’ll see!
Parameter Indication lets the host tell the plugin to display a color-based indication on a parameter, for example, whether a physical controller is mapped to that parameter over MIDI.
Remote Controls simplifies mapping faders and encoders on a hardware controller to plugin parameters. Instead of exposing a flat list of available parameters, it groups them into “pages” based on their functionality. E.g. for a virtual synth, likely “pages” would be “oscillators”, “envelopes”, and “filters”.
Even more extensions by Alexandre and other contributors are being reviewed: Note Expressions to report which note expressions are supported by a plugin, background processing, and more.
The team also continued developing side projects: clap-helpers, a reference CLAP host, extensions for the JUCE framework, and others.
How the adoption is going
This is a multi-fold question: there’s adoption by host developers, plugin developers, developers of plugin frameworks, and users.
First, there’s not much point in a new plugin API if there aren’t many hosts supporting it. When the v1.0 of the API was released, it was already known that support in Bitwig and Reaper both proprietary programs) was coming: Bitwig did their own announcement of the project, and one of Reaper’s developers had an open-source CLAP project early on.
Since then, the only big name joining them has been FL Studio (support for CLAP has been available since v21.3 beta 2), but that counts for a lot. There are some smaller names, too: MultitrackStudio, MuLab, and energyXT.
Among free and open-source host programs, Qtractor and Zrythm were the first to support CLAP plugins. Qtractor’s Rui Nuno Capela went for an implementation with support for fundamental extensions since Qtractor doesn’t support some advanced features (like surround sound or modulation). Zrythm’s Alexandros Theodotou went a different path: the program uses the host library Carla by Filipe Coelho to host plugins, including CLAP plugins. However, there is no released version of Carla with support for CLAP yet.
LMMS has a preliminary patch adding CLAP support that has been in the works for over a year and will take longer to complete. Rosegarden and MusE teams don’t seem to be working on CLAP support. There are smaller hosts like Anklang supporting CLAP, though.
The Ardour team still considers CLAP support a lower-priority task. In a public IRC conversation, Paul Davis stated:
Since we don’t do modulation, CLAP offers nothing in an Ardour context that is not offered by LV2. If someone landed a PR tomorrow with well-implemented CLAP support, we would use it, but again, users would get nothing from it other than in the unlikely case of a plugin available in CLAP format but not VST3 or LV2.
The situation is more interesting with plugins. Some new FOSS plugins come with built-in CLAP support (e.g., JC303), and many pre-existing plugins now feature CLAP support: Surge XT, Linux Studio Plugins, Dragonfly Reverb, and PeakEater are some of the more well-known names.
On the proprietary side of the spectrum, there are no big names like Native Instruments, Xfer Records, or Waves supporting CLAP. However, there are smaller developers that are well-known in the musicians’ community: AudioThing, Fabfilter, TAL Software, u-he, Vital Audio, and others. Some never released an LV2 version of their products (or only released an alpha version, like u-he) but happily went with CLAP. Some, like nakst, go for the CLAP-first approach.
A more or less complete list of hosts and plugins supporting CLAP is maintained by the CLAP team at clabdb.tech.
The third part of the adoption topic is support for CLAP in plugin development frameworks that simplify creating new plugins in multiple formats. At the moment, CLAP is supported by iPlug2, CPLUG, DPF, and NIH-plug frameworks. Initial CLAP support is also coming in the next release of Dplug, and the code is already there.
JUCE hasn’t added native support for CLAP yet. That means you still need to use the extension for JUCE, which was developed by CLAP developers.
On a relevant note, Celemony does ship its ARA SDK with support for CLAP, so technically, something like Melodyne in CLAP format is a possibility.
Finally, the most difficult thing to evaluate is how many users rely on CLAP plugins. The vast majority of 99% of plugins that are available in CLAP are also available in other formats. The few that are CLAP-only don’t have any significant market share yet. And as there aren’t many technical reasons for users to prefer the CLAP version over VST3 or AU versions, the actual adoption is likely happening when specific features are only available in a combination of a CLAP plugin and its host.
User pdxindy shares on KVR:
I certainly have a use for CLAP. Being able to use Bitwig’s unlimited per-voice modulation system and note expressions with my favorite u-he synths is a game changer for me. For my use, CLAP is the most important feature addition by any DAW in a long time.
Developers community
Although there are 34 contributors to the SDK, the vast majority of work is still done by the original developer, Alexandre Bique. Everybody else has up to 40 commits, adding up to 500 new lines of code each. However, 3rd-party plugin and host developers are actively involved, as evidenced by some of the discussions in the pull requests section on GitHub.
This situation is different in other repositories of the project. For instance, nearly 50% of code in clap-wrapper (allows wrapping CLAP plugins into another format supported by hosts that do not support CLAP) is written by Paul Bacon, lead developer of the Surge team (FOSS synths Surge XT and Monique, sampler Shortcircuit XT). It’s the same with JUCE extensions. Both repositories are part of the project and yet are virtually untouched by Alexandre.
Is this disparity between repositories bad? Not necessarily, it simply suggests that the real interest for contributors could be in integrations rather than in the API.
CLAP’s future
According to Alexandre Bique (interviewed for this particular article), CLAP isn’t so far from being feature-complete. Further work is expected to be done mainly around CLAP: in clap-helpers, clap-wrapper, and tooling in general.
A much more significant goal is to support Wasm. Alexandre finds Wasm exciting for the technical challenge it presents but also for the benefits it would bring to developers and users alike: one will be able to build a plugin once and get it to work on any OS and CPU.
In conclusion
CLAP has been facing the same problem any new API faces: when there’s already at least one very popular API available, however hostile the policy of its developers is, the market’s inertia is extremely difficult to overcome.
The interest of the developers community appears to be increasing, as evidenced by an ever-growing amount of proprietary and free/libre offerings in CLAP. It’s the pace of the growth that is hard to predict.
From a purely technical standpoint, CLAP seems to be fine. It’s capable (very much on par with VST3), easy to develop with, and licensed to allow for both FOSS and proprietary plugins (MIT). So, CLAP is not the problem here. But it’s also not just the inertia.
The industry loves blaming each other for things. To give you an idea, developers of plugins don’t support Linux, citing few commercial DAWs for Linux; developers of DAWs refer to manufacturers of audio interfaces not supporting Linux, and the latter pin it back on developers of DAWs and plugins. Thus, it would be safe to assume that the industry will take note once some big players go for CLAP support.
Bitwig was first here, but it could never be sufficient. Reaper followed suit, but that still wasn’t big enough. FL Studio getting CLAP support is big news. It won’t be the tipping point, but it will help move matters along.
In a purely speculative manner, PreSonus’s Studio One sounds like an excellent next candidate: they support the DAWproject open exchange support developed by Bitwig, and they started supporting Linux. But your guess is as good as mine.
What is clear is that if market dominance is ever to be taken from Steinberg, it would involve prying it from their cold, dead hands.
Patreon subscribers get early access to my posts. If you are feeling generous, you can also make a one-time donation on BuyMeACoffee.
