@t0m covered this in the latest Audio Programmer meetup, 1:22:09:
In short, CLAP doesn’t give plugin developers anything they don’t already have. VST, AU, and AAX cover every major DAW, and 99% of minor DAWs.
1 Like
+1 CLAP 
2 Likes
If you’re only measuring the value of CLAP in term of DAW coverage, as Tom says, JUCE already has 100% DAW coverage through existing format support, so obviously no new plugin format could possibly represent an incremental gain in DAW coverage for JUCE.
The value of CLAP is not derived from DAW coverage, it’s derived from the nature of the format. The fact that it’s an open source project, requiring license grants to developers from neither Steinberg nor Apple, subject to horrible API decisions by neither Steinberg nor Apple, and requiring approval for new features from neither Steinberg nor Apple, makes it massively valuable.
7 Likes
It does have advantages, allowing hosts and plugins to have a greater level of collaboration over a thread pool seems like a step in the right direction for multi-threaded plugins.
1 Like
It will give me great pleasure to support it, after all that faff with VST3 for no good reason 
4 Likes
Let’s please keep this thread on the current state of the juce7 branch.
If you want to see CLAP support in JUCE sooner, rather than later when the ubiquity of CLAP might be different, please create a post in the #feature-requests section and vote for it.
I think CLAP is a really good initiative for the industry, but to put an implementation in JUCE would mean that we have to stop working on other, more valuable, bits of work. There are a couple of ways this could change in the short term:
- If there’s a clear indication that a majority of our customers value CLAP support more than the other things I’ve mentioned in this thread
- If we receive funding to either offset the opportunity cost of not working on something else, or for us to bring in extra resources
We are talking to people about the latter, but the JUCE team’s time is valuable so the conversations are not straightforward. If you’d also like to talk to us about this please send me a message.
12 Likes
1 Like
Personally I’m not political enough to try to rally or poll for support for something that I happen to think is important by creating a feature request thread. I would just suggest with respect to this point you made:
- If there’s a clear indication that a majority of our customers value CLAP support more than the other things I’ve mentioned in this thread
If you are basing your determination on the outcome of a feature request thread, you are not going to get an accurate indication of interest, because the vast majority of people that pay for JUCE will never see that feature request.
The only way you could possibly get an accurate indication of interest is if you actually put the question to all of the people who pay for JUCE, maybe with an email or something. Anyway, I’ll drop the subject in this thread, just wanted to respond to that point.
3 Likes
The absence of a public roadmap for juce or even a bug tracker - something wished for many times on the forum - makes it hard to say, if we deem X or Y more important.
I agree with you that the importance of clap should be a separate topic, but I couldn’t leave that uncommented.
10 Likes
I understand that you’re lobbying for CLAP support as hard as you can, but please don’t try to twist what we are saying to your own agenda.
I didn’t say that we would base a determination solely on the feature request thread. We speak to many of our customers outside the confines of the forum. Even within the forum we know how the different sizes and types of company are represented and it is not difficult to extrapolate the data. Furthermore, we also don’t need 100% accuracy.
As I said before, I think CLAP is a really good initiative for the industry. We are not manufacturing excuses.
2 Likes
You led with “create a post in the feature request section” and followed with “if there’s a clear indication that a majority of our customers value CLAP”. The inference I drew was a pretty straight line.
Anyway, it’s been clear from this line “we have to stop working on other, more valuable, bits of work” where this is headed. 
1 Like
I have created an FR, please vote if interested: FR: Support CLAP for plugins (host & client)
Edit: Now it’s 3rd highest feature request
6 Likes
Here’s a data point for the JUCE7 MacOS drawing backends. Maybe it’s helpful for anyone doing a lot of rectangle/gradient stuff.
This is for 36 drawRect calls, each with a unique gradient with 6-8 colors.
Each data point is averaged from 20+ paint calls, measured with (the awesome) perfetto.
DEBUG
~2ms on juce7 metal (sync)
~0.250ms on juce7 (async default)
~0.250ms on juce 6.1.6 (with+without async flag)
RELEASE
~1.5ms on juce7 metal (sync)
~0.075ms on juce7 (async default)
~0.075ms on juce 6.1.6 (with+without async flag)
My thoughts:
- This is best case hardware (M1X Max) for the platform on the latest MacOS 12.3.1.
- For this particular metric, the ~20x speedup the default renderer has over the metal one is quite significant. It could be the difference between animation being possible or not on older hardware.
- I saw a lot of extra paint calls on the default renderer. Paint calls were nice and “hygienic” on the metal renderer. Although I appreciated that, for my use case (tons of rectangle drawing), the default renderer (async) is making me happy!
I’m interested in any other hard datapoints. Would be fun to cook up a little benchmarking app to help people make informed choices for JUCE drawing.
3 Likes
stepseq.lv2 works fine now, cool! and B.Sequencer is working also.
I found that LV2 GUI plugins crashes on Windows (not on Linux) when it’s closed, I’ve tested with stepseq.lv2 and x42 Equalizer
PS should I start a separate thread for LV2?
I don’t think there’s a benchmark we could provide that would be useful to people.
I’ve said this a few times in this thread, but it doesn’t look the message is being communicated very well:
Please stop referring to it as a ‘Metal’ renderer. The ‘async’ mode is probably also rendering to a Metal layer (it’s just opaque to us behind the macOS/iOS API).
The only benefit to JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS is to avoid Apple automatically consolidating redraw regions that could be rendered separately. Therefore the performance of the JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS is very highly dependent upon the extent to which Apple consolidates redraw regions. It will be extremely different for different GUIs. There are cases, in real plug-ins, where it has dropped the CPU load from 85% to 5%.
You should try enabling the flag if you think you might benefit from avoiding having Apple consolidate your drawing regions, and you need to measure the effect in your own software.
8 Likes
My suggestion wasn’t for the JUCE team, sorry if it came across that way! Changing renderers is a big amorphous thing. People have to test on their own apps, but having a head start knowing a bunch of simple rectangle/gradient drawing performs 20x better on the default is something I thought people would find extremely helpful. I’d personally find it useful to keep hearing experiences and numbers from other devs as they explore the options.
I’ve said this a few times in this thread, but it doesn’t look the message is being communicated very well
In case it helps, this was all crystal clear to me. It’s why I went to the trouble of benchmarking my use case and sharing (vs. flipping a switch because of a new shiny).
Please stop referring to it as a ‘Metal’ renderer.
I can see how the metal connotation is problematic, especially because it might accidentally connote a perf boost. I wasn’t quite sure how to casually refer to so I went with what everyone in the thread was using. Happy to never call it metal again!
1 Like
@t0m I’m pretty excited about your mentioning revamped animation classes in the last Audio Programmer Virtual Meetup.
If this is something already available on the juce7 branch, can you point me the way so I can check it out? Will just keep my eyes peeled if not.
1 Like
Didn’t @bgporter write a pretty comprehensive animation library?
3 Likes
Sure, and we’re using it at Artiphon. I don’t see how this matters to my question though.
Yes! I chatted recently with Tom a bit about its merits, nice library. It would be sweet to to tie that library to JUCE 7’s new hardware synced painting.
(Currently I’m using it extensively in tandem with AffineTransforms which helps avoid stuttering due to components being integer bound.)