About CLAP

[ifso]

One thing that caught my eye was the min and max values for parameters, but no mention of how to deal with non-linear curves (frequency and time parameters for instance) of parameters. One of the things that VST3 got right imo, was to force parameter modulation to a normalised 0-1 range, while at the same time providing functions to convert to and from normalised and scaled values for display. That way curves and scaling could be left to the plugin and it was dead simple to map a parameter to a controller knob or similar.

I agree. There should be value_to_normalized and normalized_to_value callbacks available for more practical control from plugin editor controls, host automation lane etc.

Given that there seems to be "value to text" and "text to value" callbacks for the host to convert back and forth between the actual values and their textual representations, I don't personally see a huge issue with allowing any arbitrary range. If one prefers to work with normalized (and I certainly do) then just specify [0,1] as the range for every parameter and just do the conversion for the host in the string formatting?

The issue is with automation or the above mentioned mapping to a host controller: Consider a plugin having a filter frequency parameter ranging from 20 to 20k that a user wants to automate from 20 to 80 Hz. This is three out of ten octaves or about 30% of a normalized parameter range (using a logarithmic mapping). In a linear mapping the user has to fiddle with a change of about 0.4% of the whole range. The alternative of using a range between 0 and 1 lacks the ability to set automation points to a specific frequency.

Maybe the normalization doesn't have to be in the parameter definition itself but could be done via an extension that could be used only for parameters that don't use a linear range.

[Urs]

I don't know exactly the details about the VST format. But do the developers have to pay Steinberg some kind of license fee for using their SDK? Or is it just that it isn't open source?

The VST3 SDK is open source, but under the GPL, which means that any product made with it must also be open source. If you want to create a non-open source plugin, you must get a proprietary license from Steinberg, which is free of cost afaik, but they dictate the license terms.
Frankly, I am always a bit surprised why it’s always Steinberg that gets the flak. They are the only ones of the three big formats that even offer an open source license. From what I read, e.g. AAX is much more restrictive, you have to apply to Avid for a developer partnership before you can even have a look at the SDK, and for AU I also think you have to register with Apple as a developer which afaik costs a yearly fee.

AU is fully open source and liberally licensed (a derivative of BSD I think). One could port it to other platforms, but it uses concepts that are not commonly found on Windows (plists, bundles, frameworks such as CoreFoundation).

The annual 99$ developer program of Apple is required for VST and CLAP development as well. It includes a code signing certificate that alone is worth the cost.

[Urs]

So I had a look at the clap repo (I am not a C dev, but I can very roughly read and understand), and I am all in all able to kinda understand it. Which is probably a good sign.
Couple of questions:

- Am I right in guessing that if you want a plugin with sidechain functionality, you’d add additional ports with the flag “is_cv”?

I'm not dealing with the programming myself, but that sounds about right.

- It says that i/o port reconfiguration can only be done when the plugin is deactivated. What does that actually mean? What needs to happen if a user wants to add another output for say a multitimbral instrument like a sample?

Typically a CLAP plug-in can ask the host to provide the right sequence of events. It'll say "dear host, I have some changes in my setup, can we please go back to where you activate me?"

This way CLAP ensures that everything that host and plug-in know about each other can always be dealt with in the same stage of plug-in lifetime.

This isn't uncommon. For example, in AU there are things that require a plug-in to be reinitialised. I remember similar things in VST, e.g. when changing plug-in latency.

at the moment with VST/VST3 (in Cubase for me) I have two examples of how to do/not to do:
a) Steinberg’s own Grooveagent, where I can e.g. click on a sample group and say “route this to output xy”, and the plugin/host automatically create a dedicated output and a track in the DAW, both correctly labelled with the name of the sample group. Does CLAP support such a possibility?
b) NI Kontakt. need I say more? It is a complete clusterf***, an unintuitive mess where is a matter of luck if you are able to route a sample group or instrument to an output that has just generic names and activate exactly that output on the host side, and if you change anything it won’t work unless you re-instantiate the plugin instance.

This shows why it was necessary to move from VST2 to something more modern. Maybe in their upcoming VST3 implementation NI can rectify the status quo.

(that said, I have no experience with either software, nor with bus mangling)

- Urs wrote that one possibility for compatibility to other plugins formats would be wrappers, but don’t those wrappers add an extra layer of complexity and source for errors?

To the contrary.

Firstly, CLAP is designed to minimise common errors - not bugs per sé, but a plethora of issues that are known to lead to conflicts between hosts and plug-ins. Whether or not that works out is yet too soon to be told, but from what I see the means are there (plug-ins can tell hosts that they misbehave and vice versa, plug-ins can even pretend to run in a picky host and sanity check themselves).

Secondly, there could be "once and for all" efforts to create open source or closed source wrappers and adapters. These would to a great extent bring CLAP's robustness to these formats as well. So if a CLAP plug-in is known to "behave", the wrapped plug-in will "behave". If then a hosts has issues with such a plug-in, it may be possible that the host needs fixing.

Hence, I think this will improve overall compatibility and everyone will benefit. One can not easily accomplish this with a format that has a limiting license. But with a liberally licensed format such as CLAP this is possible.

This is also an example as to why people use JUCE and iPlug: They know it just runs because all the issues have been dealt with. It's just, some people like us have other requirements and can't just switch to such a tried and tested platform.

[fese]

Thanks for the explanation, Urs. I can see the advantages of an “once and for all wrapper”, especially if it is open source. I’m not sure I would want to rely on a closed source adapter as a dev where I would depend upon others to fix bugs, but then that is probably not much different as with other libraries.

Would probably be helpful if those closed source wrappers would be provided by some consortium of multiple companies to ensure continued development even if one contributor loses interest or closes shop.

So if I understand correctly, CLAP isn’t necessarily yet another xkcd 927, but first and foremost a building block for developers who for whatever reason don’t want to rely upon frameworks like IPlug or JUCE (or pay for the latter). If it at some point succeeds in being a widely supported format, that’s a bonus (but my guess is that outside the open source world, the chicken-egg problem will be harder to crack).

As a Cubase user, I probably won’t profit from CLAP directly, but clever idea nonetheless, and good luck with the endeavor!

Edit: I probably should’ve used “probably” less often…

[moss]

Hi Urs,

great to see that CLAP is really taking shape now! I can imagine that this is a big step forward in thread management which is currently still a mess if one uses different third party plugins. Can't wait to test this in Bitwig.

Two questions:

1) Does CLAP also cover the possibilities of ARA?
2) Does it contain a concept for preset tagging and sound previews?

Cheers!

[mystran]

The alternative of using a range between 0 and 1 lacks the ability to set automation points to a specific frequency.

Why would that be the case?

The spec defines value to string and string to value methods for the plugin to implement and specifies the host should call these to convert. So as far as I can see, the raw value can be [0,1] and you can still parse "42Hz" into whatever normalize value it happens to map into (and the host can still show "42Hz" to the user even if the automation is acting on a normalized [0,1] range in some perceptually linear domain)...

...or am I missing something fundamental here?

[EvilDragon]

b) NI Kontakt. need I say more? It is a complete clusterf***, an unintuitive mess where is a matter of luck if you are able to route a sample group or instrument to an output that has just generic names and activate exactly that output on the host side, and if you change anything it won’t work unless you re-instantiate the plugin instance.

This shows why it was necessary to move from VST2 to something more modern. Maybe in their upcoming VST3 implementation NI can rectify the status quo.

So yeah, the situation in Kontakt is basically because of VST2. You can ensure things work correctly if you create your outputs in advance (say, you could have a fixed setup of 16 stereo and 16 mono outputs then save this as your default, then it's always gonna be set up like this). The naming of channels is indeed a bit problematic, but also not all DAWs refresh plugin output names when plugin changes them properly either, so the blame here is not solely on Kontakt's side.

@Urs, so Kontakt VST3 already exists, and attempts to redo the output setup were done, but it was again found that various hosts simply don't want to comply in one way or another, too many implementation differences I guess, so they kept the VST2 behavior. Not ideal, but hosts should also get their shit together. However considering the "simplicity" and "lack of ambivalence" in VST3 makes it improbable...

Also for reference: Steinberg's own HALion 6 only has a fixed output setup, you cannot change it at all. You get 32 stereo outputs and one 5.1 surround output and THAT IS IT. Could it be Steinberg themselves found what a convoluted mess they have created?

[Urs]

1) Does CLAP also cover the possibilities of ARA?
2) Does it contain a concept for preset tagging and sound previews?

CLAP does not try to replace ARA. But as ARA is freely available, we think of it as a complement.

That said, CLAP has one simple but incredible improvement over some (all?) other formats in the knowledge of the host project: It knows which bar it's currently processing. This very little gem alone allows for totally different plug-in concepts (plug-ins that map out the song itself), which would currently maybe rely on ARA (I don't know).

CLAP itself allows the host to load plug-in presets through the plug-ins own format (or any other format, whatever the plug-in supports), but afaiaa this does not extend to tags or previews. A companion open standard project to CLAP that we are not directly involved in (even though our plug-ins will support it) allows DAWs to access the preset databases of plug-ins, which I suppose also allows for the host to tap into tags. I don't know anything about previews, with our experience with NKS I have a bit of mixed feelings about them (i.e. I think there should be a more elegant solution). Maybe that's why I don't know anything about that (probably just ignored the discussions).

[Cyoon]

Yeah, re Surround, let's see how it goes. The DAW manufacturers involved at this point of time don't afaik really deal much with surround. OTOH I just saw that another one joined the conversation, and they do surround afaik, so we'll see if there'll be more flags at some point.

Which is a realy pity. Would love to have proper surround suport in Bitwig.

How did the u-he customer survey come along regarding Ambisonics btw?

[Urs]

Would probably be helpful if those closed source wrappers would be provided by some consortium of multiple companies to ensure continued development even if one contributor loses interest or closes shop.

Sure. 30 developers with a AAX/VST2/3 license could do this in a joint venture and it would still be closed source.

We have put a lot of thought into this, and some proof of concept is on its way.

xkcd 927

Well, of course it is yet another standard. But then again, another standard left the scene, so maybe there's a vacancy for a "keep it simple, stupid" approach.

[Urs]

Yeah, re Surround, let's see how it goes. The DAW manufacturers involved at this point of time don't afaik really deal much with surround. OTOH I just saw that another one joined the conversation, and they do surround afaik, so we'll see if there'll be more flags at some point.

Which is a realy pity. Would love to have proper surround suport in Bitwig.

How did the u-he customer survey come along regarding Ambisonics btw?

Dunno, the guys are still preparing the data, so we'll probably have at the full picture after the holidays.

[ifso]

...or am I missing something fundamental here?

No, I didn't think about the textual approach in combination with a generally normalized range.
Being quite used to paired normalized/plain parameter values, grabbing the new idea of normalized parameters with plain text representation needed some time to sink in. Thanks for elaborating.

[moss]

1) Does CLAP also cover the possibilities of ARA?
2) Does it contain a concept for preset tagging and sound previews?

CLAP does not try to replace ARA. But as ARA is freely available, we think of it as a complement.

That said, CLAP has one simple but incredible improvement over some (all?) other formats in the knowledge of the host project: It knows which bar it's currently processing. This very little gem alone allows for totally different plug-in concepts (plug-ins that map out the song itself), which would currently maybe rely on ARA (I don't know).

CLAP itself allows the host to load plug-in presets through the plug-ins own format (or any other format, whatever the plug-in supports), but afaiaa this does not extend to tags or previews. A companion open standard project to CLAP that we are not directly involved in (even though our plug-ins will support it) allows DAWs to access the preset databases of plug-ins, which I suppose also allows for the host to tap into tags. I don't know anything about previews, with our experience with NKS I have a bit of mixed feelings about them (i.e. I think there should be a more elegant solution). Maybe that's why I don't know anything about that (probably just ignored the discussions).

Thanks, Urs.

[Held]

Since I started using Bitwig, I've wished for polyphonic modulation(automation) for VSTs so many times. I really hope CLAP is a huge success and spreads far and wide.

[antic604]

That said, CLAP has one simple but incredible improvement over some (all?) other formats in the knowledge of the host project: It knows which bar it's currently processing. This very little gem alone allows for totally different plug-in concepts (plug-ins that map out the song itself), which would currently maybe rely on ARA (I don't know).

Damn, the more I read about CLAP the more it strikes me how much it's inspired by Bitwig, e.g. most Bitwig's modulators are synced to transport, so they know where in the project the playback is and always output the same value in that particular place. That's awesome to have in plugins!