About CLAP

[schwa]

Separating metadata from plugin processing code is Good Actually. There are plenty of VSTs out there that will try to decompress gigabytes of sample files or try to validate the license or pop up an error message when all the host wants to know is what the name of the plugin is.

[crickey13]

Any ETA of CLAP format?

Boy oh boy, I do love revising my VST backups, so magnanimous of you, Steinberg, thank you.

[dawhead]

I'd also note that this is precisely why the GMPI effort took place back in the aughts, and why it was so tragic when the MMA f**ked that process up so badly that nothing ever came of it.

...except GMPI...

https://github.com/JeffMcClintock/GMPI (under construction, not all the code is up yet).

Well, and arguably LV2 as well

https://lv2plug.in/gmpi.html

[pdxindy]

I'd also note that this is precisely why the GMPI effort took place back in the aughts, and why it was so tragic when the MMA f**ked that process up so badly that nothing ever came of it.

...except GMPI...

https://github.com/JeffMcClintock/GMPI (under construction, not all the code is up yet).

Well, and arguably LV2 as well

https://lv2plug.in/gmpi.html

You know, this is a thread about CLAP. After a while, your frequent posts about LV2 start to seem like spam.

[mystran]

Separating metadata from plugin processing code is Good Actually. There are plenty of VSTs out there that will try to decompress gigabytes of sample files or try to validate the license or pop up an error message when all the host wants to know is what the name of the plugin is.

I'd argue that the main problem with VST2 at least is that you can't really query any metadata without creating an actual instance of the plugin first.

I agree that separating metadata from processing (or even plugin instances) is good, yet I'd also argue that having a programmatic interface to query that metadata without creating a plugin instance is better than storing it in an external file because (1) it's much easier to make sure such metadata always stays in sync with the plugin and (2) it allows one to make the metadata dynamic, for example by potentially exposing additional features depending on what is available on the system (or what types of license is found, etc). In fact, as long as "shell plugins" are supported (not that I'm exactly a huge fan of the concept), even just giving the host a list of the plugins available might involve some dynamic logic.

The way I see it, the only truly reasonable way to provide metadata in a separate file (when point 2 above is not a concern) is to write a tool that extracts it from the binary and add that tool into your build process, but even then you still risk the possibility that the two might go out of sync when they are two separate files on the user's system.

[teilo]

Any ETA of CLAP format?

Boy oh boy, I do love revising my VST backups, so magnanimous of you, Steinberg, thank you.

MFM2 is already distributed in CLAP format. The future is now.

[dawhead]

How are the licenses different for host developers than for plug-in developers?

No idea - never seen a Steinberg license in my life. But that wasn't my point - what I meant was that we have essentially a single product, not many. That makes our relationship to 3rd party technology slightly (or maybe a lot?) different than a plugin developer with multiple plugins. Also, as the ProTools and Logic examples show, where a host supports only a single format, there's the nominal option to say "we just don't do that" (although I don't think that's a good choice for anyone, mostly).

But yeah, you do open source software. We don’t. As depressing as it might be for you, we have different requirements.

The only requirement I've seen that seems germane so far is that a 3rd party is not able to change the technical specifications of an API at will, nor change the licensing terms at will. Open source development not only has those requirements, but is arguably about those requirements at a rather deep level.

I don't find it depressing that anyone does proprietary development. I have a deep respect for you and all the other people out there doing that, and I do my best not only to personally respect your licensing choices but also to encourage others to do the same (understanding that open source is a choice, and not everyone makes that choice).

[dawhead]

In fact, as long as "shell plugins" are supported (not that I'm exactly a huge fan of the concept),

Which plugin developers other than Waves uses shell plugins at this point?

[crickey13]

MFM2 is already distributed in CLAP format. The future is now.

Well, that's good. I hope Reaper and all my favorite plugin devs implement the CLAP format ASAP and then Steinberg can kiss my sweet ass.

Is it already available for everybody to adopt or about to happen soon?

[Urs]

In fact, as long as "shell plugins" are supported (not that I'm exactly a huge fan of the concept),

Which plugin developers other than Waves uses shell plugins at this point?

We do. For AU, AAX, CLAP and VST3.

[Urs]

Any ETA of CLAP format?

Boy oh boy, I do love revising my VST backups, so magnanimous of you, Steinberg, thank you.

MFM2 is already distributed in CLAP format. The future is now.

Well, it's in there because it's part of our development process - we simply don't want to strip our installers of it only to put it back in later. It's WIP though, we will have to publish an updated version of MFM 2.5 to make it work in current and upcoming hosts.

[Compyfox]

Sadly, the "big three" (Steinberg, Apple, AVID) will probably never adapt CLAP.

But it was indeed long overdue, and I'll keep my eye on the project.

In all these years, U-HE was the sleeping dog that everyone underestimated. It's time we switch from being nice to biting. If it will be possible to keep VST2 plugins alive in... whatever means this might turn into the next months (even in CubEndo and co)... heck you got my full support.

[Urs]

Separating metadata from plugin processing code is Good Actually. There are plenty of VSTs out there that will try to decompress gigabytes of sample files or try to validate the license or pop up an error message when all the host wants to know is what the name of the plugin is.

I think a CLAP should be called misbehaving if it actually took that much time to return the meta data.

IIRC Alexandre deliberately wanted to avoid redundancy for the very points Mystran makes. Out of sync meta data happens quickly, and some people also wanted to be able to have a CLAP plug-in change its parameter layout/properties, e.g. based on channel layout.

[Urs]

It's time we switch from being nice to biting.

Nah. We have a positive and inclusive message.

I'd much rather bring CLAP forward than argue about CLAP vs AU/AAX/VST. Surely, people constantly ask about other formats. All I can say is, we have a specific issue that we solve with CLAP, and we think our concept benefits many. People somehow invested in other formats may see this differently, or they simply ignore our message, I don't know. To me it isn't as much about replacing other formats as it is about removing the barriers between them, and to other platforms.

[Teksonik]

I applaud the concept of CLAP and wish you success going forward.

The question I would have at this time is how much work is it going to be for DAW developers to add CLAP plugin support?

I suppose the answer to that question will go a long way in determining how the format will be accepted.

I don't think most end users care what format their plugins are in as long as they are stable, lightweight, and contain all desired features. The way I look at it, an open format will almost certainly benefit me as an end user so I'm excited to see what the future holds.