FR: Support CLAP for plugins (host & client)

Support CLAP for plugins (host & client)

Haven’t tested it so far. Instead I’d really appreaciate official support for CLAP for JUCE.


I would Also appreciate official CLAP support for JUCE!

in the process of this: drop vst2 support. then there are no formats left anymore that don’t support sample accurate parameter changes and it will be easier for juce to work on that


I understand, but I’m I absolutely against dropping vst2 soon, because it’s still widely used and needs active support in case some future OS update (or whatever) breaks something (even when its not related to vst2).

(And I don’t wanna keep a second outdated JUCE repository in parallel; with all implications like two different apis for shared code between my product line)

This kind of abstraction is what defines a framework like JUCE.

I think sample accurate parameter changes can be implemented in vst3&CLAP and simply ignored in older formats. One does not prevent the other.


yeah, that makes sense. just wanted to say putting the work into supporting the new format would probably feel more rewarding if there is also a chance to implement its unique features :slight_smile:

i just wanted to push this post because i thought of a new argument for clap support in juce lately that i want you all to consider:

i was talking to a youtuber who only reviews plugins of developers who support all formats and he enlisted vst, aax and au, on windows and mac. he does that because he came from pro tools and always felt frustrated about plugin reviews of plugins he can’t use. he only wants to bring joy to everyone though. but i thought, while his goal is noble, his approach is not very good, because aax and au are both format that try to exclude themselves from the majority of musicians and audio engineers. if the moral goal is to support the formats that really try to unite everyone and to maintain plugin culture, then the focus should be on formats that actively want to be implemented in all DAWs, which are basically just VST and CLAP. (and lv2, tbf, but it kinda never took off for some reason)
So that’s why I’d suggest that native integration of CLAP into juce should have a higher priority than these other formats that don’t even try to make themselves available for everyone. If they get very unpopular because of that, maybe that makes more DAW-developers focus on the good formats, which would give every developer an easier time supporting every format and also make every user happier, because no one must feel excluded anymore.


Another push for CLAP - REAPER:

REAPER 6.71: Old in the Body, Not in the Mind
Changelog items below may include • links to more information.

    - add support for CLAP plugins
    - support "cockos.reaper_extension", which returns a reaper_plugin_info_t structure for REAPER API access (see reaper_plugin.h) 

1 Like

Another push for CLAP :wink:

As MultitrackStudio, Bitwig, and now Reaper support CLAP plugins we plan to release all our plugins with CLAP support soon. See also

1 Like

I would also like to see CLAP supported in JUCE. :pray:

1 Like

I would also like to see CLAP support. But adding CLAP support also means sample accurate modulation, automation, and the integration of expressions for me.

I would like to see some bigger changes and simplifications in the JUCE wrappers to make this possible (sample accurate handling of parameters, expressions, and MIDI data in the same function → processing method) :


Hey - what’s the latest with JUCE CLAP support? Is this the right thread to be checking?

1 Like

It seems that more and more modern plugins are only making clap plugins, at least for windows and Linux. It would seem a very logical thing to do to support it in the reference framework for audio related applications.
I’m building a host and would be very interested in being able to host CLAP :slight_smile:

Thank you !

Which plugins are only releasing as CLAP? I’ve not observed this, so would be interested in seeing which plugins are taking that path.


I’m also curious about this. It seems like a pretty poor business model…

1 Like

Regency Is A FREE Phase-Distortion Synthesizer By Nakst - Bedroom Producers Blog

I think the problem is where you first think business model when people think sharing and open-source…

The point is, VST makers ARE adopting this as a standard, and it would be a shame that JUCE is getting behind on this evolution. I guess the unofficial Clap juce module is good for creating plugins, I’m more interested in hosting, and no idea where to start :slight_smile:

Also, not saying JUCE team HAS to do it, just bringing some more thoughts to the topic.

Cheers !

I am working on a Clap host myself. Hosting Clap plugins is not too hard to do. (Of course not super easy, either…) I’d advice against basing the Clap hosting on the Juce AudioProcessor stuff, though. There’s no good way to incorporate the new advanced Clap stuff that way, as far as I can see.

IMHO, Juce itself probably shouldn’t bother with Clap support before they have the infrastructure to support the differentiating Clap features in Juce, like the sample accurate automation, the non-destructive parameter modulation and the per-note modulation. Clap plugins without those features are for end-users basically just like the existing Juce-based VST3 and AU plugins, so I don’t really see the point in supporting the Clap format with just a limited feature set.

One could of course make the argument that supporting Clap would be good just because of the more open license, but users don’t really care about the licenses the developers have to deal with, they only care about tangible new/different features.


Would you be interested in sharing it as a juce module, so anyone can benefit / give feedback / improve this ?

Right now I think even just basic support for CLAP in JUCE would show the community that it’s not just ignored.
Choosing to do or not to do it, or when to do it is one thing, communicating on it is another :slight_smile:

My wild guess is that more and more people will do it, both in spirit of open-source and because it offers more possibilities and [maybe] is easier to implement ?

My Clap hosting code is not fully featured, has some idiosyncrasies related to the other DAW/host code in my app and is probably going to go through extensive changes. But I’d be happy to eventually share it, the whole app is going to be open source anyway. (The source code is not available now, though, the application is way too early in its development to be of any use to anyone.)

Personally speaking, I’d never put business model over open source and accessibility. However, it seems to me that a vast number of JUCE users on this list are commercial developers. And right now, they can get their plugins into all major hosts without having to disrupt their development cycle.

Anyhow, I think I’m going to bow out of this discussion. I wish Clap all the best, I’d love to see it succeed. But in the meantime, I’m not in any particular hurry to support it.