About CLAP

[Urs]

Yes, as far as I understand it, extensions are either draft or final for the current version of the plug-in format.

(But while I post here a lot, I'm really not that much involved in the development side... I'm more involved with bringing people together and telling them about CLAP. So I know about the bigger picture, but I don't know all the particular little things)

[DRMR]

We'll definitely support CLAP if it gets added to JUCE.

Will you finally support Linux too, then?
(and what about LV2, that should be coming to official JUCE shortly)

[DRMR]

but support for clap is not yet planned by the juce team, so someone else has to do it - for the time being, at least

The problem with this is that you'll end up in the same boat as LV2: maintaining a fork, or several forks, for many years until the JUCE team does their own in-house (re-)implementation.

[Music Engineer]

The problem with this is that you'll end up in the same boat as LV2: maintaining a fork, or several forks, for many years until the JUCE team does their own in-house (re-)implementation.

yes, that's likely the process it has to go through. perhaps it's not such a good idea to lobby them right now for support while they are still groaningly busy at doing lv2. the timing would perhaps be suboptimal. but maybe in 2 years or so, it will become apparent that this is the next big thing since vst1/2 (which i fully expect...yeah! i'm very optimistic and excited about this!) and when they realize that, they will do it anyway. during this time, i'll be fine with using a 3rd party wrapper or may even write my own

[sjaehn]

I think it's always a good idea to think about free and open source standards including FOSS audio plugin formats. The main principles of open source include:
* participation,
* improvement, and
* copy.

OK, as discussed before there are already some other free and open source plugin multi-platform standards around. Like VST3 and LV2. And don't forget the old LADSPA and DSSI plugins.

I fully agree not to go the VST3 way. We know what Steinberg did with the VST2 programmers. OK, there is now a GPLv3 option in VST3 in contrast to VST2. But Steinberg still has got rights on VST3. At least the name. And you never know ...

Steinberg controls the development of VST3. And there might be a conflict of interests (especially between Berlin and Hamburg ). Why to feed a competitor?

But there's still LV2. It has got an active community. New ideas are discussed and may be implemented in new releases. You can ask the community. And there's no competitor leading the project. You are welcome to participate as well.

Too many free and open source standards may lead to a diversification. And this only helps the big names.

[glokraw]

The worst situation is always, when the only option is tied down by the corporate gatekeepers.
Apple, Steinberg, ProTools all are the total opposite of "open".

When their blinders are pulled off, they can see that all the man-hour costs of maintaining their closed standards can be reinvested in creating musically useful and wonderful products, which if masterfully done, might earn them more profits than whatever licensing fees are currently extracted, not to mention increasing goodwill in the eyes of the buying public, and the music industry as a whole.

But that success would have to be earned in an openly competetive world, and some people fear competition, as it defines and re-defines winners and losers for all to see. Hence some will try to stamp out freedoms, wherever they begin to grow.

Scroogism is incredibly and irreparably BORING

An open plugin standard not dominated by corporate politics and it's beancounting hordes, will lead to more and better music, a worthy goal that most people will embrace. Which U-he have embraced from their inception.

To everything, there is a season...a time to embrace

[wangeroge]

As soon as I have time, I will port the CLAP headers also to Object Pascal and then add support for CLAP plugins to my own yet unreleased DAW, which has already long support for VST2.x and VST3.x.

Everybody is creating a DAW nowadays. Behringer, Universal Audio, some random guy on KVR...

[bero]

As soon as I have time, I will port the CLAP headers also to Object Pascal and then add support for CLAP plugins to my own yet unreleased DAW, which has already long support for VST2.x and VST3.x.

Everybody is creating a DAW nowadays. Behringer, Universal Audio, some random guy on KVR...

Well, you should not underestimate me and do not judge prematurely without knowing more about it.

[Markus Krause]

One host developer and a developer at a major plug-in manufacturer expressed great dislike of a MIDI-only solution for note events. That was at an early point and hasn't been questioned since. So we simply offer both, as e.g. has always been the case with AU, without too much struggle there at all. Hence I don't see this as a problem.

A bigger problem would be "no MIDI at all" which may at first sound like a good idea ("hosts take care of things") - but in the end it means everyone has to reimplement the little there is again and again to support multiple formats. So we think that it should be up to the plug-in developer to decide whether they wish to go low level (MIDI, MPE) and stay consistent, or high level (Note events, NoteExpressions etc.) and do several specialised implementations (and MIDI again for the things that aren't available in the respective format...)

No MIDI at all is a no-go. Steinberg went the easy way with VST3. It's more simple for the host dev. But comes at the cost of limitations for plugins. Let's not repeat the design flaws that Steinberg did with VST3.
Apart from this all other plugin formats except VST3 support MIDI. MIDI 2.0 is also on the way.
A MIDI abstraction layer can be easily done as an optional module within the plugin itself.

[Urs]

Fully agreed. My argument was always that a high level implementation could be provided by helper classes.

[phazed]

I think, certain plugins like editors for hardware synths have to deal with MIDI anyway.

Related question: if you want to do something similar to Elektron Overbridge, what's the way to go here?

[wangeroge]

Does CLAP include advanced controller integration? Not just MIDI Learn or Mackie/HUI. The controller should know what the parameter name, value, min value, max value, type (fader/knob), color, x/y position etc. of every knob/fader is. If it belongs to the CLAP API, ANY controller will work with ANY plugin.

[bm1000]

Does CLAP include advanced controller integration? Not just MIDI Learn or Mackie/HUI. The controller should know what the parameter name, value, min value, max value, type (fader/knob), color, x/y position etc. of every knob/fader is. If it belongs to the CLAP API, ANY controller will work with ANY plugin.

Yes, this would be a killer feature!

[baconpaul]

The problem with this is that you'll end up in the same boat as LV2: maintaining a fork, or several forks, for many years until the JUCE team does their own in-house (re-)implementation.

yes, that's likely the process it has to go through.

Right now i can build and run Surge and other JUCE plugins on my laptop as a clap against unforked JUCE 6. Will let folks know the recipe after Christmas once we wrap up a few more bugs and stabilize a couple of API points, but just dropping a note here since this is a popular thread with several devs on it to dispel the idea that clap will require a forked JUCE. I've been able to make it all work with an out-of-juce-tree MIT licensed extension with the only real requirements on the plugin being being CMake / Juce 6 plus adding a couple of lines to your CMakeLists.txt.

(My first pass was indeed a forked JUCE so the comment is not unreasonable, but I realized a way a few days ago that didn't require that. And it would indeed be best for the JUCE team to support this one day, but this code give us a chance that Surge can release as a CLAP on day-one once 1.0 is stable).

[rafa1981]

Interesting. Good work!