Good to know that you’re on the good side 
sorry if I can come strong on commercial/open-source, I’m fighting my whole life for more open-source, so when I think I hit a wall that only exist because of capitalism, I can get a bit defensive 
Your point is totally valid of course, it would just be sad not to see JUCE be a leader in the open-source [r]evolution
2 Likes
Chasin’ chasin’
No mention of CLAP in the survey result…so the community seems not to much interested in it.
Sadness…i find myself using CLAP format more and more…more stable, powerful, flexible, efficient than VST3.
1 Like
I wouldn’t say that the community isn’t interested, given that this is with currently 80 votes the highest voted FR.
I forgot if it was in the questions, but I did check the box if it was there.
The juce team just made strong statements they won’t consider it, so that’s maybe why the survey was steered away from that topic.
Yes. This being the most voted topic in the feature request category is a clear indication that there is some demand for CLAP support.
However, what these votes don’t capture well is the context of all the other things the JUCE team could be working on. We’ve been speaking to lots of different people about CLAP support and there’s a persistent pattern where they are very enthusiastic about CLAP in isolation, but that enthusiasm wanes substantially if CLAP support would come at the expense of working on GUI rendering performance or a larger fee for a JUCE license. This is evident in the survey results where “additional plug-in formats” was one of the least desired features. Of course “CLAP support” and “another plug-in format” are not identical, but they are close enough to provide some context.
I don’t think we’ve made a statement that completely rules out CLAP support. Our current position is that at the moment, and for JUCE 8, the JUCE team’s time is better focused on other things. It’s not that CLAP support would not be a worthwhile addition to JUCE, it’s just that there are other more valuable things we can work on. Things like broader CLAP adoption within the audio software industry is an important dynamic quantity and we’re talking to some of the key software manufacturers. I expect things will change over the next 12 months or so and we will continually reevaluate our position.
5 Likes
CLAP is nice and all, but I don’t think JUCE can leverage what’s actually useful about CLAP without a metric shit-ton of complicated work by the team.
I don’t really see much point in it for the moment, afaik only 2 “major” DAWs support it, and only something like one of those dropping support for all other plugin formats would make JUCE support for CLAP (or a subset of CLAP capability for speedy deployment) worthwhile. And let’s face it, no major DAW is suddenly going to drop VST/AU support unless they intentionally planning to annoy their users.
2 Likes
…which never happens (I am looking at you, Emagic/Apple - or you, Steinberg VST2)
lol, yeah I didn’t think that statement through entirely.
I forgot Cubase has dumped VST2 support. I wasn’t aware that Logic had supported other plugin formats before, unless you mean how they dropped Windows support entirely after Logic 5 when Apple acquired them?
It’s a chicken egg problem, but juce is part of the chicken and the egg. It condenses to the question, do we want an open plugin format, and for that you have to be a bit idealistic about it. This is not a rational decision.
3 Likes
Exactly, the JUCE users are the developers AND the developers customers.
The JUCE team does an amazing job and is of course master of their time.
I think in favor of CLAP, it has strong points that play well together with topics, that warrant remodeling of the framework that are already scheduled anyway, like e.g. sample accurate/deterministic parameter automation.
1 Like
I think having so much professional audio software under license agreements owned by third-parties is an unhealthy thing for the industry. Furthermore, as an open source project itself, JUCE is philosophically aligned with things like CLAP.
Considerations like this are included in our evaluation of CLAP’s value; there is no need to abandon rational decision making.
4 Likes
I think having so much professional audio software under license agreements owned by third-parties is an unhealthy thing for the industry. Furthermore, as an open source project itself, JUCE is philosophically aligned with things like CLAP.
Considerations like this are included in our evaluation of CLAP’s value; there is no need to abandon rational decision making.
You make me curious:
Is there an official view on things like this from Juce’s owning company?
I can imagine they have a different view on what is unhealthy or not for the industry.
Can they influence “direction decisions” for Juce?
How about putting this as a straight-up single question survey to the Juce community so you can clarify how people responsed to the “additional plugin formats” question?
I can understand why it was done this way; asking a generic question is usually better for a long-view on strategy but it is not always going to give sufficient resolution for short-term planning on topics that have specific considerations for people today. Phrasing the question as “additional plugin formats” is going to fly under the radar of developers who have not even heard of it or care about licensing considerations and answered in a more general technically minded way. I would argue that in the case of CLAP this is a question that would interest the legal teams of plugin companies, I bet few of those got the opportunity to have their opinions represented here because it is a developer-focused questionnaire.
As written there is no way to differentiate between open source and closed source additional formats. Some people/firms may highly value a liberally licensed plugin format that does have support in some DAWs already in the hope of seeing greater adoption (currently CLAP is the best chance of getting it), vs not wanting to see another closed source SDK supported (of which we have plenty already).
Maybe something like “Do you want us to prioritise support for the new CLAP format in Juce v8?” with a link to what CLAP is and its technical and legal benefits (maybe engage with the team so they can set out their case), and the consequences of supporting it like diverting attention from other high priority tasks (and specify what those are for Juce 8) so people can purposefully reply in context and even consult with the relevant people in their company if needed.
Full disclosure - I answered that I do not want additional formats. In my case I don’t get much from CLAP technically, I don’t really feel too threatened by the commercial SDK issues with other formats and I don’t have a strong moral position against them either, so I doubt I would use CLAP even if it is implemented. I’d rather have faster GUIs. But I understand others feel very strongly in the other direction and I’m not sure they really got their chance to have their position represented fairly in the survey as the way a question is asked greatly influences how it is answered.
If you were to simply ask a direct question about it then we can settle this matter for the short and medium term, otherwise we are just going to go around in circles for years with more and more bickering about it.
I call for The Great CLAP Referendum!
1 Like
OT, not JUCE related: the last referendum worked like a charm… SCNR
The answer will be a mixed bag, regardless of how you ask
I completely understand both sides of the CLAP debate.
I think an immediate pragmatic approach to allow 3rd party support of CLAP plugins. E.g. the “Major Missing API point” section of GitHub - free-audio/clap-juce-extensions
I’d be fine if CLAP support came in the form of a 3rd party module if it was drop-in like the LV2 support was.
1 Like
This is already somewhat addressed by the inclusion of LV2 in JUCE…
The survey is absolutely not our only data point and I tried to make that distinction in my previous post.
We have spoken directly to many people about CLAP and we will continue to do so going forward. We are communicating with key software manufacturers.
We also recognise that “CLAP support” and “another plug-in format” convey different information and we are well aware of that difference. Had we phrased the question differently it is obvious we would have gotten different results. I was simply supporting our empirical observation that enthusiasm for CLAP wanes when discussing it with people when broader context is considered, not stating anything definitively about the will of the community.
1 Like
My enthusiasm is not waning.
1 Like
I tried to figure out but neither lv2plug.in nor wikipedia were a big help (or I didn’t see it):
Is LV2 cross platform? In theory and in practice?
The JUCE implementation supports hosts and plugins on Windows, macOS, and Linux. Third-party hosts and plugins will have differing levels of support, but the LV2 API and most of the supporting libraries can target all of these platforms. REAPER is a popular host that supports LV2 on Windows/macOS/Linux OSs at time of writing.
3 Likes