CLAP: The New Audio Plug-in Standard

[fruen]

On U-he s website.


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

[Largos]

Doesn't matter how good it is, everyone will still call it CRAP.

[Death]

I just read about this. It sounds promising but I imagine they'll have a hard time getting a lot of the well known plugin companies to adopt anything open-source. Still, us Linux users will surely see some good benefits from this

I'm quite interested to know what some of you plugin developers think though as you understand this stuff much better than most of us..

[sadko4u]

Are there any hosts that support CLAP at this moment?

[mike@overtonedsp]

To quote from https://lwn.net/Articles/893048/ (my emphasis)

Developers want to write once and be able to compile for all architectures, OSes, etc. JUCE is the de-facto standard and overall king in this realm. Without JUCE buy-in, a new format will just muddy up the waters for development and be another thing that users will think they want developers to support, and developers will hate it for that reason. If this format doesn't solve more than the Steinberg licensing problem, it's not likely to help anyone.

Speaking from experience, generally (commercial) developers tend to hate new formats because it means users won't buy their existing products unless they support the new format, typically you can't charge anything more for the new format, and by definition, when its first released nothing supports it, so you are left with months of work to do, which you can't charge for, just to get back to where you started. Time better spent developing new products. One of the reasons for this new standard appears to be dissatisfaction at Steinberg's licensing around VST2 and VST3, but its interesting to note the extent to which Steinberg had to go to 'encourage' support for VST3. Ironically, that in itself should be a lesson to anyone proposing (and hoping for acceptance of) a new format (unless it has some 'must have' killer feature that everyone is desperate for, and unfortunately I don't see that here)

[glowrak guy]

CLAP offers plenty of new capabilities for expanding plugin features, and according to U-he, is extremely easy to implement.
All of the costs, limitations, and flaws of the vst/vst3 'standard' will become optional, and the developers working on the open-source code are among the best. The lone-wolf and small-shop coders will soon have expanded capabilities without licensing fees, and without locked-down code, and bug reports will not be sorted at the whim some Steinberg bean-counters.

Steinberg can simply join in the CLAP party, and unleash their coders to create great new plugins and daw functions, that could earn them more than any lost licensing revenue, and solidify their place in the future of computer based music. If the ego's get kicked out of the boardroom, it's a no-brainer to support clap. More music tools, more freedoms, more money
(and parent company Yamaha certainly would favor of such an outcome!)

[nils]

Steinberg can simply join in the CLAP party, and unleash their coders to create great new plugins and daw functions, that could earn them more than any lost licensing revenue, and solidify their place in the future of computer based music. If the ego's get kicked out of the boardroom, it's a no-brainer to support clap. More music tools, more freedoms, more money
(and parent company Yamaha certainly would favor of such an outcome!)

If ego had not been a factor, they would have chosen LV2.

[Linuxmusician01]

To quote from https://lwn.net/Articles/893048/ (my emphasis)

Developers want to write once and be able to compile for all architectures, OSes, etc. JUCE is the de-facto standard and overall king in this realm. Without JUCE buy-in, a new format will just muddy up the waters for development and be another thing that users will think they want developers to support, and developers will hate it for that reason. If this format doesn't solve more than the Steinberg licensing problem, it's not likely to help anyone.

Speaking from experience, generally (commercial) developers tend to hate new formats because it means users won't buy their existing products unless they support the new format, typically you can't charge anything more for the new format, and by definition, when its first released nothing supports it, so you are left with months of work to do, which you can't charge for, just to get back to where you started. Time better spent developing new products. One of the reasons for this new standard appears to be dissatisfaction at Steinberg's licensing around VST2 and VST3, but its interesting to note the extent to which Steinberg had to go to 'encourage' support for VST3. Ironically, that in itself should be a lesson to anyone proposing (and hoping for acceptance of) a new format (unless it has some 'must have' killer feature that everyone is desperate for, and unfortunately I don't see that here)

I agree. And from a users perspective: yet another format to add to the confusion? LibreOffice never succeeded in convincing users to use their format.

Unless developers begged for a new format I do not see the added value of another format. Even if it's better/stable/more easy than anything else. It's like the Playstation 3. Development was way, way more difficult for it than for the Xbox 360. However, demand for PS3 games was so great that developers ported/developed literally every single game for it. Sad, but true.

Finally, U-he is, afaik, not a player in the market that is so powerful that they can force it upon devs & users. Steinberg can, unfortunately.

[alex stone]

To quote from https://lwn.net/Articles/893048/ (my emphasis)

Developers want to write once and be able to compile for all architectures, OSes, etc. JUCE is the de-facto standard and overall king in this realm. Without JUCE buy-in, a new format will just muddy up the waters for development and be another thing that users will think they want developers to support, and developers will hate it for that reason. If this format doesn't solve more than the Steinberg licensing problem, it's not likely to help anyone.

Speaking from experience, generally (commercial) developers tend to hate new formats because it means users won't buy their existing products unless they support the new format, typically you can't charge anything more for the new format, and by definition, when its first released nothing supports it, so you are left with months of work to do, which you can't charge for, just to get back to where you started. Time better spent developing new products. One of the reasons for this new standard appears to be dissatisfaction at Steinberg's licensing around VST2 and VST3, but its interesting to note the extent to which Steinberg had to go to 'encourage' support for VST3. Ironically, that in itself should be a lesson to anyone proposing (and hoping for acceptance of) a new format (unless it has some 'must have' killer feature that everyone is desperate for, and unfortunately I don't see that here)

It's worth mentioning here that Juce(7) are adding LV2 to their current formats with official support for both hosts and plugins. And with HISE using quite a bit of Juce, we could soon be able to build plugins with HISE in LV2 format.

[robbert-vdh]

Are there any hosts that support CLAP at this moment?

On Linux, Bitwig is the only that's publicly available although their 4.3 version is still in beta so for now you'll need a license with an active upgrade plan to use that. I feel like 4.3 final should be out sooner rather than later though. On Windows/macOS there's also MultitrackStudio with CLAP support.

[robbert-vdh]

To quote from https://lwn.net/Articles/893048/ (my emphasis)

Developers want to write once and be able to compile for all architectures, OSes, etc. JUCE is the de-facto standard and overall king in this realm. Without JUCE buy-in, a new format will just muddy up the waters for development and be another thing that users will think they want developers to support, and developers will hate it for that reason. If this format doesn't solve more than the Steinberg licensing problem, it's not likely to help anyone.

Speaking from experience, generally (commercial) developers tend to hate new formats because it means users won't buy their existing products unless they support the new format, typically you can't charge anything more for the new format, and by definition, when its first released nothing supports it, so you are left with months of work to do, which you can't charge for, just to get back to where you started. Time better spent developing new products. One of the reasons for this new standard appears to be dissatisfaction at Steinberg's licensing around VST2 and VST3, but its interesting to note the extent to which Steinberg had to go to 'encourage' support for VST3. Ironically, that in itself should be a lesson to anyone proposing (and hoping for acceptance of) a new format (unless it has some 'must have' killer feature that everyone is desperate for, and unfortunately I don't see that here)

The main difference here is that CLAP is something that most plugin and host developers seem to actively want. I've chatted with developers from multiple dozen companies as well as FOSS devs who are all very excited about the prospect of a plugin API that's liberally licensed and dead simple to use, without being limiting at all. CLAP has all sorts of cool shiny features like modulation in addition to automation, polyphonic modulation, polyphonic note expressions that just work, and thread pools, but all of those features are merely a consequence of CLAP's simple design and not the primary reason that most of those devs are excited about CLAP. The main draw is that CLAP is permissively licensed, well designed, and developed for and by the community of plugin and host developers using it. I don't have any commercial audio development credentials myself, yet it was still super easy for me to get involved with the project and everyone involved has been putting in a ton of great work making CLAP a plugin standard for the future. And regarding the design, I've personally seen a developer port a big name plugin made using their own handwritten VST2+VST3+AU+AAX plugin framework to CLAP in the matter of hours with help required. That's purely an anecdote of course, but I'd say that that does speak for the APIs design. Since as a newcomer, CLAP's been able to learn a lot from previous plugin APIs so it take all the good bits, strip out the unnecessary ceremonial parts, and design everything in such a way that reduces the risk of running into common current plugin and host specific implementation bugs.

[mike@overtonedsp]

...that reduces the risk of running into common current plugin and host specific implementation bugs.

This is mostly because only one host supports it at the moment.

[robbert-vdh]

...that reduces the risk of running into common current plugin and host specific implementation bugs.

This is mostly because only one host supports it at the moment.

Have you considered reading through the plugin API yet? This defensive API design comes in two forms. First, the invariants/preconditions for all functions are well documented, and every function call has thread safety guidelines which indicate that a function must be thread safe/non-blocking, may only be called from an audio thread, or must be called from the main thread, with a simpler and thread safe way to request a main thread callback if needed. This was done because past experience has told us that quite a number of sometimes difficult to track down host host<->plugin compatibility bugs came down to unclear threading models, and plugins and hosts having incorrect expectations. We also spent a lot of time and effort to design APIs to make them as difficult to misuse as possible. Simple examples of this are a complete lack of mandatory lifetime management, and URID mapping being limited to a single place (namespaces for events brought in by custom extensions, if you only use core events you don't even need to worry about this). I could name some more specific examples from the APIs themselves, but I'd encourage you to read through the interfaces first and maybe give some feedback on the parts you like and the parts you didn't like. I'd recommend starting with entry.h, followed by plugin-factory.h, and finally plugin.h before diving into the extensions.

[WforWoollyMammoth]

Does this format offer any benefits that could convince more plugin manufacturers to port their offerings to Linux? (maintenance issues, library compatibility across distros etc.).

I like Bitwig and u-he very much (I am a customer of both companies), so I'm definitely not against this format. Let's see if it takes off. I doubt VST2/VST3 support will be phased out anytime too soon by the DAW companies.

[sjzstudio]

If this format really helps Linux audio move forward, that's a good thing. In addition, we desperately need more audio interface support on the Pro side.