CLAP... thoughts?

[Urs]

Can CLAP be considered a MIDI plugin-in API?

A CLAP plug-in can even have no audio processing at all.

It is a wonderfully simple and efficient concept.

For example, baconpaul hacked together a CLAP that would take MIDI Input, pass that through to the output, but for each note would pass NoteExpressions with tuning for a microscale. So the following CLAP would be mircotuned.

There's a very high rate of head-explode emojis in the dev chats. Because CLAP makes things possible.

[4damind]

I don't think there will be a format that replaces all others in the near future (even if it would make technical sense). But just because something is unlikely today doesn't mean it might work someday

Ideally, there should be an open format that is royalty-free and open source ("FLOSS"), with some sort of committee (and not a single company) defining the features and API. Most importantly, it should be responsive to the needs of plugin developers - and that seems to be a problem with some formats like VST3.
CLAP seems to be able to do just that and more. So the question is not necessarily if we need this new format but rather if it will reach a certain threshold and find enough supporters.

[ThomasHelzle]

https://forums.steinberg.net/t/vst3-and ... /201879/27

And then there is this: ^^^^^^^

Yeah, and the reply from the Steinberg Dev reminds me of the classic discussion on the Adobe board ages ago about the alpha channel in EXR files. The Adobe programmer - some Mr. Cox IIRC -explained to the whole graphics industry that they are wrong in how they use the alpha channel in EXR.
He continued even when the original developer of the EXR format showed up and explained that no, Mr. Cox interpretation was never how EXR alpha channels were intended to be used...

Programmers can get quite obtuse and in some cases drift far away from reality...
As can companies when they age badly.

I love that CLAP even has it's distinct smiley on KVR already:

[Tj Shredder]

If only half of those listed here do support clap in a timely manner, I promise VST will be dead in five years and the first host appear that don’t need to support VST anymore. At least if we get useful wrappers… And we would finally get a real cross platform plugin format accepted by everybody (except Apple and Avid…)

Actually Avid is listed right below...

I guess the just watch it to see if it disturbes their business plan...; - )

[mystran]

In the thread is the following comment by Arne_Scheffler from Steinberg

your frustration comes from the misunderstanding that you can build MIDI plug-ins with VST. VST describes an audio plugin API. That you could misuse version 2 for building MIDI plug-ins was not intended. You need a MIDI plug-in API which does not exist across hosts

This quote is actually a great summary of why we need an open API like CLAP. The last thing any developer wants to hear is that they can't have feature X because Steinberg doesn't feel like it's intended and the feature Y that they've been relying on for the past 10 years needs to be "fixed" so it's no longer possible, because a perfectly working solution was "abuse."

[EvilDragon]

It's an extremely myopic stance. Instead of looking ahead and anticipating needs.

[Urs]

If Avid support CLAP - and I'm sure they will - their revenue will hike.

[Vortifex]

Edited

[Urs]

Yes, for a short amount of time (unless they use a supported framework anyway).

There are many good reasons though to do this, including better stability and an independent future.

[mystran]

Is this going to add to developer workloads? Seems like they already have a ton of formats/standards etc to spend their time on. Disclaimer: I know nothing about plugin development.

Additional APIs or platforms generally add some bulk short-term workload as you add support and then some long-term workload when you need to fix things that break. The short-term cost here doesn't seem too bad (ie. the API doesn't seem like it necessarily forces you to redesign everything), but the long-term cost is harder to predict. I've been getting the vibe that at least the plan is to try and keep CLAP fairly stable so you wouldn't need to be chasing changes all the time. Time will tell how well that works out.

In any case, even though some developers like to complain about the workloads from multiple APIs or platforms, it's typically not because the workloads themselves are necessarily excessive, but rather because everyone hates it when they need to keep changing things that used to work fine simply because the API vendor decided that it's time to break something for the sake of breaking things. Most of us would rather spend our time developing something new than trying to figure out what's broken this time. If CLAP manages to avoid this, then the short-term cost of adding support won't be a big deal for most of us.

[foosnark]

Getting out from under Steinberg seems like an inherently good thing.

As a modular user, I feel that anything that improves communication between plugins and the host is helpful. The parameter modulation seems nice, and would ease some of the annoyances I face once in a while in Bitwig. Hopefully also, some of the arbitrary limitations on I/O in Bitwig devices are going to be lifted.

I doubt anyone is going to suddenly stop offering VST plugins/hosting in their products in the next couple of years. So to the average musician this is neutral news at worst, and potentially quite good news as we start seeing better performance, fewer crashes, more features.

[Held]

Additional APIs or platforms generally add some bulk short-term workload as you add support and then some long-term workload when you need to fix things that break.

On the plus side, if Avid actually adds CLAP support, developers can eventually drop AAX, so the number of supported formats would stay the same.

[PieBerger]

Additional APIs or platforms generally add some bulk short-term workload as you add support and then some long-term workload when you need to fix things that break.

On the plus side, if Avid actually adds CLAP support, developers can eventually drop AAX, so the number of supported formats would stay the same.

AAX still isn't M1/X/2 native AFAIK, so maybe the reason Avid are interested is because CLAP codebase is (and has no platform OS specific dependencies) and it will be less work for them to add support than to update and continue supporting AAX.

[anttimaatteri]

its time to go on. and per usual when someone goes on, its also time for the little and big shitters.
the only thing i could complain is that the format is called CLAP instead of SMACK ^^

[EvilDragon]

AAX still isn't M1/X/2 native AFAIK, so maybe the reason Avid are interested is because CLAP codebase is (and has no platform OS specific dependencies) and it will be less work for them to add support than to update and continue supporting AAX.

Don't think AAX itself has any problems with ARM. It would be PACE holding back AVID in this case.