About CLAP

[Music Engineer]

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.

that sounds great! thanks for your effort!

[defiantnerd]

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...)

In general, the MIDI side of things are often not considered well enough in the standards and it might be worth a shot to look at MIDI 2.0.

In general, as a plugin developer, I prefer MIDI as raw as possible, it makes it much easier to implement things. Semantic flags ("played live, timestamp etc.") are very welcome. CLAP would still need some of this stuff.

[NWSM]

A very good name for Audioplugins...i also like kick, snare, drum, hit, plug

[Jeff McClintock]

But: Please don't expect a full blown roll-out in the next few months! Even if we offer ready-to-go CLAP plug-ins, we can't speak for our partners on the hosting side, and CLAP is still in development, i.e. specs might change a bit.

I notice that the call stack into a CLAP plugin involves a little more indirection than some other formats. i.e. The pattern is: the DAW calls a function (the 'helper')...that calls a function (in the plugin). So every operation takes two function calls instead of one.

Are you interested in hearing suggestions for tweaks to the ABI to make CLAP a little more efficient?

[HarmonicD]

I think this is gonna be a pretty big thing, given a bit of time and support from host vendors. If the "CLAP consortium" gets at least Reaper, Studio One, Live (especially Live), I'd say it's gonna become pretty interesting.

+1

[rafa1981]

Are you interested in hearing suggestions for tweaks to the ABI to make CLAP a little more efficient?

I haven't looked at the API a lot, but are the function calls involved short lived and done at high frequency/data rate? Is the indirection providing value? Can the helper inline clap functions with LTO enabled?

An extra indirection might not be that important. Given the people that is involved and the benchmarks results they have been running it has probably been considered. This is of course just a guess, I might be wrong.

[MrJubbly]

Having witnessed Steinberg's strong-arm tactics and attempts to force developers to abandon VST2 in favour of VST3, I want to be supportive as possible (as an end user), for a non-monopolised and controlled 'free' alternative.

If this 'CLAP' is it, then so be it. As a customer, all I really want in the future, is to be able to install a single format for my plugins, with as much compatibility moving forward as possible.

i.e. I wouldn't want to run into a situation where in a few years time, after CLAP's initial release, we're introduced to CLAP v2, which does not support 'auto migration' for legacy projects saved with CLAP v1 instances of existing plugins, etc. This is just a headache for customers who just want to have quick and easy access to their purchased software without worrying about all the plugin formats, etc.

Given the whole drama earlier this year surrounding Steinberg's stated stance regarding their support/depreciation of VST formats, I decided it was perhaps inevitable that most of my plugins might eventually become VST3 only (similar to how 32-bit support was largely removed from many plugins previously in favour of 64-bit only versions).

Since then, I have expended a lot of time over this past year, manually migrating countless instances of various plugins (from different developers) from VST2 to VST3 within my existing projects (to hopefully 'future proof' them as much as is possible).

This task would have been so much easier and faster, had many of these plugins also supported 'auto migration' between the VST2 and VST3 formats. However, most of my plugins did not (which, I had been informed by various developers was due to internal mismatching plugin IDs, between the two VST formats).

I was especially disappointed that most of my used plugins did not support the feature, such as those from Fabfilter, Kilohearts and U-he.

Much respect however to those plugin developers who did (or were able to) support VST2 to VST3 'automatic migration', such as 'Valhalla DSP', 'Synapse Audio', 'Sonic Academy' and 'Applied Acoustics Systems'. I wish other developers could have done likewise.

If it's not possible to integrate an auto migration feature from VST2/VST3 to CLAP, then I could perhaps stomach such an awfully time-consuming task of manually migrating each VST3 plugin instance to it's CLAP equivalent just ONE MORE TIME.

But please, if CLAP is the proposed solution for the plugin format wars, please think about the end users and ensure that any future updates to that format, CLAP2, etc. consider from the very outset, such future 'automatic migration' issues that would really help your customers out.

[Urs]

CLAP offers an option for automatic support for migration from legacy plug-in formats. The plug-in manufacturer can supply the identifier, a conversion of the preset format (if necessary, e.g. it isn't any work for us) and a mapping for automatable parameters. Then hosts can open projects containing legacy formats with CLAP instances instead.

The reason our VST3 plug-ins don't auto-convert from VST2 is because at that time it wasn't clear to us that there was such a feature and how it worked. We have kindly requested Steinberg to provide a path forward for us, but they had no interest in helping out. In fact, they recommended to write software to "hack" Steinberg project files in a related case (ID mismatch), which we did. The "conversion by convention" is simply a bad design choice that was predestined to fail for many, particularly in a time when "documentation" did not provide much context on there topic, or any topic.

[coolblinger]

VST3 does have a way to migrate VST2 plugin instances as long as both the plugin (JUCE supports it, so most do) and the host supports it. I've never tried it myself though since I use Bitwig and they don't support this. Steinberg's VST3 documentation has been down for at least a week now (great) so it's a bit difficult to link to right now, but the process is described under the 'Compatibility with VST 2.x or VST 1' in this wayback machine link: https://web.archive.org/web/20210121024 ... ml#faqVst2. The idea there is that the VST2 version of the plugin reports the UID of the equivalent VST3 component, and then the host calls `IComponent::setState()` with the VST2 plugin's state. For automation compatibility you'd need to make sure that the parameter IDs stay the same.

[Dewdman42]

I for one would love to see vst2 and vst3 die like a Dinosaur. I am excited to hear about clap which appears to be a simple replacement. That’s all we need is a simple replacement thst is not encumbered by Licensing. I for one, missed the deadline to get grandfathered into vst2 license and I have less then zero interest in vst3 development.

Does anyone know if a vst2 license will be needed in order to develop a clap plugin with a vst2 wrapper in order to teMporarily get through the phase where only a few hosts support clap?

[EvilDragon]

Any of the plugin vendors that have a VST2 license could make a closed source wrapper for VST2 that you could use, AFAIK.

[AnX]

I for one would love to see vst2 and vst3 die like a Dinosaur. I am excited to hear about clap which appears to be a simple replacement. That’s all we need is a simple replacement thst is not encumbered by Licensing. I for one, missed the deadline to get grandfathered into vst2 license and I have less then zero interest in vst3 development.

Does anyone know if a vst2 license will be needed in order to develop a clap plugin with a vst2 wrapper in order to teMporarily get through the phase where only a few hosts support clap?

So, you missed out on a vst2 licence, so you hope it dies because....?

Rather odd

[Dewdman42]

What a stupid question

Yes I hope it dies. Steinberg is a poor steward for this task. We need an open source solution to take hold, vst2 is not that complicated it’s just ridiculous that the industry is beholden to Steinberg in order to develop plugins that can run in nearly all hosts, based on a header file owned by Steinberg, the poor steward.

My question about the vst2 wrapping is whether that is a compile time wrap, which I suspect it is, and would probably require vst2 license.

Once all or most hosts support clap it will never be an issue again

[Urs]

My question about the vst2 wrapping is whether that is a compile time wrap, which I suspect it is, and would probably require vst2 license.

In my favourite scenario WrapClap Inc. (an as of now imaginary outfit) will acquire some idle developer with a VST2 license. They'll create an adapter that they'll resell through CLAP developers (who, as resellers, don't need a license for the SDK) for 1 cent a pop, or maybe 1$ bulk a year.

[EvilDragon]

WrapClap Inc, a subsidiary of u-he.