CLAP was originally developer Alexandre Bique’s private project: In 2014, while he was porting u-he plug-ins to Linux, Alex encountered several problems with existing plug-in formats, and became convinced that creating a plug-in should be a lot easier. He quickly developed a rudimentary format, called it CLever Audio Plug-in (CLAP) and published it on Github. Although CLAP drew some attention, it basically just sat there for several years.
Fast forward to May 2021 when Urs Heckmann was looking for a simple open source “base format” that could be wrapped to any other plug-in formats (see below for the reasoning behind this). As CLAP looked like a promising solution, Urs reconnected with Alexandre, who liked the idea of developing CLAP further and pitched it to his current employer, Bitwig.
Bitwig and u-he started CLAP as a joint venture, but it soon became clear that more people needed to be involved for the sake of a wider perspective. Within about a year, a team of over 20 CLAP developers emerged.
In June 2022 Bitwig and u-he decided that the core extensions were ready, and announced the release of CLAP version 1.0.
Let’s talk about the reasoning and concepts upon which CLAP is based
Working within a standard format should ideally be fun, not a challenge. To this end, CLAP uses consistent names, methods and concepts while avoiding unnecessary bloat.
Frustrated by the lack of a clear path towards realizing their ideas for a plug-in or host application, young talent tends to look elsewhere.
A clear standard should prevent common bugs, leading to more stable software than environments that leave room for (mis)interpretation.
One example of how CLAP improves on the status quo is that each function can either be called on the main thread or on a realtime thread. This is clearly documented, and test code is available. Furthermore, a plug-in can always ask the host which thread it’s on, avoiding any danger of misinterpretation.
Another example is how the plug-in and host communicate with each other: The host object provides the plug-in with functions it can use for direct queries, and they can notify each other about any unexpected behaviour. These built-in tools avoid common problems which are often hard to debug. Furthermore, there is an “interop-tracker”, a central location where the community can be notified about any such issues so that they can be solved as soon as possible.
CLAP’s simple design is also efficient, especially because of how easy it is to maintain extensions: new ideas and trends can find their way into CLAP very quickly. We think that CLAP will play a defining role in shaping the audio software ecosystem, acting faster and more efficiently than closed formats ever could.
The original incentive for developing CLAP was to create an alternative base format for plug-in development. Many plug-ins are being designed with old and limited formats which represent the common denominator between most available options.
Replacing everything in those legacy formats with CLAP is a manageable refactoring job. Once that’s done it becomes possible to incrementally add modern features such as Note Expressions, time stamped parameter changes and Parameter Modulation - features which, although supported by many formats, have not yet been widely adopted.
Putting CLAP at the core of the codebase enables developers to leave “common denominator” constraints behind, giving them an easy path towards implementing up-to-date features such as Parameter Modulation.
To help CLAP gain momentum we are working on wrappers that effectively convert CLAP into several popular formats. The burden placed on each developer to maintain support for these formats will be replaced by a collaborative effort. The experience that goes into the wrappers should lead to generally more robust and stable support for these formats.
The key to this concept is CLAP’s liberal license. Wrappers can be created from CLAP to any format or platform, even those with restrictive, proprietary licenses. Only an open license format such as the “MIT License” can act as a go-between for all formats.
The wrappers represent an alternative to popular frameworks for developers who don’t need a “big solution”, as well as for companies who already have a codebase centered on a particular legacy format (or one which is hard to maintain).
Companies with large codebases, multiple platform support etc. can find synchronizing their releases with OS updates or format-specific dependencies rather challenging. Much effort goes into coordinating the internal release schedule with those dependencies, and releases often have to proceed in stages, doubling the effort for testing and other repeated tasks. With wrapping, the schedule can be decoupled from format-specific dependencies – instead of updating products in stages, the product and its wrappers can be updated independently, minimising the need for beta testing, communication etc..