About CLAP

[Music Engineer]

I see your point. I guess a clap mechanism could optionally allow a clap plugin to register the various VST, AAX etc. identifiers it used in its other format plugins with the host, and then the host can automatically match those.

yeah - that sounds good. the host could inquire them whenever a new clap plugin is discovered and then store them away for later migration purposes. "database" is perhaps a slightly exaggerated term for such a storage

[Urs]

As I wrote before... check the Github repository. There are (draft) extensions that solve such migration issues.

[MrJubbly]

As I wrote before... check the Github repository. There are (draft) extensions that solve such migration issues.

What could end users of the various DAWs do to help with regard to encouraging our DAW developers to proactively support and implement such VST/VST3 to CLAP automatic migration features ~ Once CLAP becomes a more finalized and commonplace plugin format option for released software?

Will these (draft) extensions you mention be developed (and documented) to such a point whereby implementing them within DAWs should be a clearly defined and straightforward task for most DAW/host development teams to integrate support thereof? Or will the onus be placed upon those DAW development teams to instead dedicate a lot of R&D time to integrate such extension support within those hosts?

I'm just trying to assess the scale of the task. Because, if we customers lobby our DAW companies to include such 'VST/VST3 to CLAP' migration support (similar to how some DAWs already currently have for 'VST to VST3' migration), they will likely then assess whether it is worth doing so from their perspective, based upon various factors, not least of which being, how difficult or time-consuming of an undertaking that might be for their own development teams.

Clearly, I myself know very little about such processes, so for all I know, this kind of extension support could fall anywhere between being a massive undertaking to something as simple or straightforward as adding a few lines of extra code here and there to an existing infrastructure.

Finally, may I ask what has the initial response been like from the various DAW development teams regarding this proposed CLAP alternative to Steinberg's VST/VST3 plugin formats? Have many other DAW companies reached out to you for information regarding this format with view for possible future DAW implementation.

Or is it more of a case that they may only become more interested in supporting it once the CLAP format reaches sufficient levels of mass popularity within released plugins for their customers?

I would appreciate any feedback on these issues.

Thanks

[Urs]

It's late here and Im might have had one glass of red too many. Hence my short answer: Those extensions are very straight forward and simple: "Here's the ID and name of a xxx plug-in whose preset format I can handle" and "Btw. the parameters m...n of that format relate directly to the parameters p...q of me, should you have automation stored".

It's all far from rocket science. The appeal of CLAP is that developers don't have to study obscure concepts or patterns in order to write a sturdy piece of code. That also works for concepts like migrating from one plug-in to another, or one format to another, or both.

[MrJubbly]

It's late here and Im might have had one glass of red too many. Hence my short answer: Those extensions are very straight forward and simple: "Here's the ID and name of a xxx plug-in whose preset format I can handle" and "Btw. the parameters m...n of that format relate directly to the parameters p...q of me, should you have automation stored".

It's all far from rocket science. The appeal of CLAP is that developers don't have to study obscure concepts or patterns in order to write a sturdy piece of code. That also works for concepts like migrating from one plug-in to another, or one format to another, or both.

Thank you very much for your no-nonsense reply, red wine and all .

That's very good news to hear. It will be useful information to have in my arsenal when I inevitably lobby the various DAW developers to include CLAP and such migration features into their software (y'know, just in case they try to fob me off with some excuse like: "it's too difficult", etc.)

I wish everyone all the best in the continued support and promotion efforts of CLAP as a popular replacement format and hope we can all effect a mass migration towards this much fairer format from the previous legacy Steinberg formats.

God willing, we shall succeed!

[teilo]

God willing, we shall succeed!

Deus vult!

[blue monk]

I have one issue with a sample library for NI Kontakt. I suspect that this might be impossible to fix because of the plugin standard.

I want to automate parameters (ADSR envelope parameters in particular). In this Kontakt-library, I can't directly automate any of these. I need to assign MIDI-Controllers.
Setting up MIDI-controllers all the time would disrupt the creative flow and might actually require a significant amount of time overall.

My suspicion is that this could not be changed because when you load an instance of Kontakt, Kontakt has no information which libraries are going to be loaded and thus can't announce the automation parameters to the host DAW.
My assumption is that a plugin has to announce those at the time of instantiation and cannot announce new parameters later.
Is that correct?

If it is correct then this would be a feature that could be helpful to add in future plugin standards.

[EvilDragon]

In Kontakt if you can assign MIDI CCs to controls, you can also assign host automation parameters. See Automation->Host Automation tab in the left side browser. A lot of newer libraries actually already come with automation parameters already assigned (since these host automation assignments can actually be created from the script). Kontakt allocates 512 empty automation slots in advance, then instruments are free to fill them up.

[blue monk]

In Kontakt if you can assign MIDI CCs to controls, you can also assign host automation parameters.

Thank you for the information. Perhaps I misunderstood the support, when I asked them. I will have to look into that again. Actually, I refrained from buying another library from the vendor because of this.

[Funkybot's Evil Twin]

I agree with blue monk in principal though. Some modular plugins like Amplitube, Slate's VMR, and others do that thing where they reserve generic automation parameters, you load a module, then if you want to automate it, you have to take the extra step of mapping the module parameter to the automation parameters to create the link. It would be great if Clap allowed for dynamic declaration of FX Params. So if I load an amp sim module or whatever, those FX controls are automatically available for parameter mapping. Would save developers some headaches with these types of plugins too.

[Urs]

It would be great if Clap allowed for dynamic declaration of FX Params.

It absolutely does, and as far as I recall, concerns by early adopting host manufacturers were met by recent changes or extensions or documentation to the protocol. I've only briefly followed the conversation though, I've mostly reticulated splines during recent months.

[fese]

I've only briefly followed the conversation though, I've mostly reticulated splines during recent months.

That sounds dangerous be careful when you do that! Always wear safety goggles!

[Urs]

I've only briefly followed the conversation though, I've mostly reticulated splines during recent months.

That sounds dangerous be careful when you do that! Always wear safety goggles!

Always! One never knows how much reality may disintegrate if the curves accidentally align the wrong way.

[Funkybot's Evil Twin]

It would be great if Clap allowed for dynamic declaration of FX Params.

It absolutely does, and as far as I recall, concerns by early adopting host manufacturers were met by recent changes or extensions or documentation to the protocol. I've only briefly followed the conversation though, I've mostly reticulated splines during recent months.

That's awesome. Thanks!

[Aikido123]

One thing I find so frustrating about the VST plugin format, as well as the Midi protocol, is the way patch browsing and patch changing are (not) handled. Most vsts have terrible UI for browsing the patches they support, and DAWs have zero access to those patch names and zero ability to change them dynamically. And saving and loading user patches is different in every case.
I haven't seen anything all that different in the Midi 2 spec either for browsing patches and using a better program change protocol either.
Does Clap have any innovations or improvements in this area? And does it incorporate Midi 2 support?