If you use CMake, then juce support is already in progress: A set of tools allowing JUCE 6.1 + Cmake to build a CLAP | BestOfCpp
3 Likes
I do like your enthusiasm and optimism, but I think you are underestimating the task to write wrappers for all the plugin formats. Not only you need to come up with a good design to put everything in one common interface, you also need to maintain it. And then there are hosts which treat plugin standards differently (although they are standards), so you also need to take care of and maintain that. In my opinion this is a huge task actually.
Good luck though, it would be amazing if you accomplish what you’re after and I’d be totally in!
1 Like
…or:
- Update to VST3 and get over it.
There will be some abandoned plugins that will cease to exist. A great opportunity to write a better version of it.
2 Likes
Agreed, but why not support an existing open source framework like LV2 instead of reinventing the wheel?
1 Like
Obligatory XKCD reference 
:
9 Likes
LV2 has had a chance and it didn’t fly. There is a lot more to the story then just technical capabilities. You have to get developer and consumer buy-in. That just didn’t happen with LV2. Hey the LV2 team can keep trying to make it happen I don’t fault them but CLAP already has more inertia and will probably take off. Sooner or later juce will need to embrace it
There are numerous hurdles for juce to become fully compliant with vst3 and the juce team has not done anything about that for years. The vst3 model is substantially different from vst2 and it’s just not that easy. Hacks are used and juce produces only partial vst3 support without a complete api redesign. However clap is much more similar to vst2 and will fit in well with the juce approach also.
Let the clap team worry about how to wrap clap as vst3
1 Like
Is this the official repo:
Or am I in the wrong place?
Yes. There are a couple long winded threads about it on Kvr also
clap needs to be officially supported by juce! now is the perfect time to push it because even end-users are angry at steinberg
1 Like
I was looking for this too, once, the possibility of a simple VST3 wrapper for VST2 plugins.
Steinberg themselves could toss one out in minutes if they gave a **** about host developers.
As it is, anyone who gets into DAW development from now on will have a permanent disadvantage next to those who were already in it and still have lifetime VST2 licenses.
Any one of us could actually write the code for such a wrapper, as long as we didn’t publish it in our own names. I’d wager there are a few devs out there who were lucky enough to pick up that license who’d be happy to publish the result in their own names, as MIT or BSD or what have you. Then the rest of us could simply link to that on our software webpages.
So if you code the wrapper and just convince someone with the license to publish it, it should be unassailable.
3 Likes
Exactly, and JUCE/Roli would be the perfect candidate to officially distribute such a wrapper.
This would benefit JUCE users in general.
Can’t dispute that.
I suppose the proportion of plug-in developers to host developers is so huge that anyone working on the interface is mostly going to target plug-in developers.
Just a quick side note: JUCE is no longer owned by ROLI. At present time, it’s owned by PACE
Hallelujah. I knew that, but I still enjoy reading it.
JUCE without ROLI would be an even better candidate to offer such a wrapper.
Without being inside it, I would not celebrate too loudly.
Roli had it’s flaws, but no need to kick someone who is down.
No offense intended.
I can take the prices and the hype over things that’ve been in the MIDI standard for 30 years, but the mandatory privacy invasion tacked on to an open source library affected me directly. I dropped JUCE completely because of it.
Seems they are getting up again, as they announced a new version of the fabulous Seaboard device.
-Michael