Our introduction to Linux audio and MIDI
plugin APIs ended with a mention of
the Clever Audio Plugin
(CLAP) but did not get into the details. CLAP is an MIT-licensed API for
developing audio and MIDI plugins that, its developers feel, has the
potential to improve the audio-software situation on Linux. The time has
now come to get to those details and look at the state of CLAP and where it
is headed.

When CLAP resurfaced in late 2021 after years of radio silence, xkcd #927 references were a popular
response in all discussions about it. But there are a number of serious
questions to ask about this API as well. Does CLAP actually compete
with the other audio APIs available on Linux,
including VST3, LV2, and others? Is it a viable
alternative? Does it address problems that developers have with other APIs?

The backstory

Alexandre Bique started working on CLAP in 2014. In a nutshell, he
wasn’t happy with the industry dominance of Steinberg’s VST API, but he also
wasn’t happy with some LV2 design decisions.
In 2015, Bique was hired by Bitwig as a software engineer, where he’s
been working ever since. That’s pretty much when the project’s activity
ground to a halt for the first time. Bique then resumed development in
early 2016, then stopped again in October 2016.

When Steinberg started aggressively retiring VST2, Urs Heckmann, the creator
of the proprietary u-he synths, contacted Bique and told him that he liked the
CLAP API’s simplicity. He also asked if Bique wanted to finish it, to which
Bique said “yes”. So in April 2021, Bique resumed work on CLAP, and has
been tirelessly hacking on it ever since. There have been multiple releases
of the API in the last several months, for the first time since 2015.

Right now, v0.24.1 of the CLAP SDK is available (tagged in
Git). The specification is close to being final. It might undergo
some further revision, but Bique is mostly working on code examples now and
expects to ship v1.0 soon.

What’s different about CLAP

The reasoning behind the creation of CLAP is multifaceted, being at the same
time
ethical, legal, and technical.
In a post
at KVR, Heckmann claims that the main reason for CLAP’s existence is its
liberal licensing. He also mentions
a strong governance motive:

As plug-in developers we always feel like our products are
second-class citizens in the DAW [digital audio workstation]
ecosystem, as if the plug-in standard forms a harness of what we
can do and what we can’t do. As someone expresses it so nicely, “as
if the host puts its fingers into the plug-in and directs it”. CLAP
feels a lot more on equal level, which is already expressed by
having a host object and a plug-in object. The host isn’t a
shapeless god entity, it’s just another struct that we communicate
with. […]

Current formats are maintained by host developers with a
conservative product philosophy. A very short conclusion here is
that some of the people who support CLAP want to switch from the
back seat to the steering wheel of what a host/plug-in environment
could make possible. And I’m absolutely certain that the hosts and
plug-ins which do the switch – not just adoption, but also
implementation – will gain market share.

Other reasons listed by the CLAP team are technical: fast
plugin scanning for hosts that need to update the list of available
plugins, controlled multi-threading, metadata for plugin categorization,
etc. All these features are also available in LV2, though.

CLAP also takes into consideration some criticism that LV2 received from
developers over the years, and thus it has neither RDF 1.1 Turtle metadata (too
lengthy to write by hand, requires build system enhancement when
automated), nor versioned extensions (dealing with those is
cumbersome). There are even more LV2-specific issues that CLAP does not
appear to have, like heavy, under-documented APIs, design limitations that
even the LV2 maintainer thinks call for a partial API deprecation, and more.

It’s still difficult to make a case for or against CLAP as
compared to LV2, because people arrive at new APIs with preconceptions and
older APIs’ baggage. I’ve definitely seen developers praising the ease of
creating a CLAP plugi