What do you think about the new CLAP standard?

There’s a new plugin standard available which is called CLAP. https://github.com/free-audio/clap

It is free and open source and supports modern use cases like multi threading, MPE and even embedded systems. It seems to be backed by quite some companies. It also looks like headless plugins are possible with it.

What does MOD Devices and the community think about this? Is it even suitable for the MOD platform? Could it help to bring more plugins into the MOD ecosystem by lowering the bar for entry?

4 Likes

Clap is focused on desktop plugins, a few features MOD relies on (like DSP/UI separation and real / non-normalized parameter ranges) are intentionally not supported under Clap.
There is very little use for MOD to support such format.
It is much more likely we will see VST3 as supported format in MOD compared to Clap.

9 Likes

Not entirely true. The clap example plugins actually show a mechanism to “proxy” UI requests for remote interfaces → https://github.com/free-audio/clap-plugins
The proposed CV spec is still extremely limited. It does seem that it is quite an extensible system, but to integrate this with MOD would take significant development time.
With official LV2 support coming to JUCE7 that will be a lot more interesting for MOD, especially in the short term.

5 Likes

That is for quite the different target. Basically the clap example demonstrates an “external ui”, not a “remote ui” as needed for MOD.

For proper DSP/UI separation, the spec itself needs to have API methods for arbitrary message passing between the DSP side and UI side.
On LV2 we have atom ports on DSP side (from which data can be forwarded to UI) and on UI side there are dedicated functions to both receive and send arbitrary messages.
For VST3, communication can be done with the host application/context messages API (I have only used UI->DSP messages for now, which work fine)
Clap intentionally has no such feature, as their authors are against the idea. From their point-of-view such APIs are too hard/bothersome to deal with, and rarely needed.

4 Likes

Afaik any such API can still be proposed through an extension. It might not be as nicely integrated (LV2 Atoms are certainly about the most flexible you could do), but could still be possible.

2 Likes

True, but not being part of the core spec makes it so that it is just ignored most of the time.
On LV2 land, we get DSP/UI separation by default. Plugins have to do a little dance with UI instance-access extension to break this separation.
For the simpler plugins, it is often easier for developers to not deal with it at all, and let the DSP/UI message passing do its thing.

More complex plugins tend to go for the instance-access usage and break remote UIs, specially if they target any plugin format other than LV2.
The LSP collection is a nice exception to this rule though, as far as I know all their plugins have DSP/UI separation at the core

4 Likes

Thanks for your comments and discussion! :slight_smile:

But couldn’t this be still a chance? From a developer perspective who develops plugins for CLAP, it might be easier to implement this extension instead of having to maintain a whole new LV2 version of my plugin. (Leaving the effort to build such extension and integrating it into the MOD platform aside)

OMG VST3 support confirmed!!1 :laughing:

3 Likes

Vst3 support confirmed after expression pedal orders complete ; )

6 Likes

Well mod-host is also opensource. If you make it happen (including any necessary extensions) then anything is possible :wink:

3 Likes