About CLAP

[antic604]

Anyway point is it's not a huge deal if a DAW can't do polyphonic modulation, the modular nature of Bitwig is cool, but it's not necessary to everyone.

Then what would be the benefit for the dev to make an effort and port their plugin to yet another format? Or is there an expectation there will now be a breed of new, CLAP-only plugins just because it's free and open?

[DRMR]

For any developer who starts out or wants to have a solid base, CLAP is gonna be an easy choice. All other formats can be abstracted from it.

In that case I look forward to an LV2 wrapper so I can use CLAP-based plugins in all my favorite LV2 hosts.

[Urs]

Quick answers:

- the computational overhead of wrappers/adapters is next to non-existent. It wasn't an issue in 2002, it's certainly not an issue in 2022. Many, many, many plug-ins are wrapped/adapted without anybody ever noticing it or questioning it.

- there will certainly be more DAWs supporting it. But again, my motivation to do this is completely independent of host adoption.

- not all hosts and plug-ins need to support every feature of CLAP. Some of the new feature are easy to integrate, some are conceptually challenging, for both hosts and plug-ins. But: The ease of adoption is mind boggling compared to certain other formats.

[jussi_neuraldsp]

I noticed that MIDI event size was set to 3 which means that MIDI 2.0 messages are not supported. Just increase the event size to 16 bytes, MIDI 2.0 messages have sizes of 4, 8, 12 and 16 bytes.

[Lesha]

Happy to see this happening.

[Urs]

I noticed that MIDI event size was set to 3 which means that MIDI 2.0 messages are not supported. Just increase the event size to 16 bytes, MIDI 2.0 messages have sizes of 4, 8, 12 and 16 bytes.

This is a convenience function for quick adoption from existing formats.

I haven't looked at it lately, but I remember there to be a MIDI method for arbitrary packet size.

In any case it's in the spirit of CLAP to support MIDI completely, not just reluctantly. I'll ask Abique about it next time we speak.

[rafa1981]

This has happened. Several JUCE based open source synthesizer plug-ins have been ported to CLAP, almost literally overnite...

The JUCE team itself expressed no apparent desire to deal with CLAP...

The iPlug2 team on the other hand is very supportive to the cause.

I assume the plugin format being so simple that it was easy to add to JUCE then. As soon as there are some hosts and plugins supporting it JUCE will get on board I guess. As they are commercial I guess they need to see if there is demand for it.

[excuse me please]

Well... at least it's not called "Clapslutz" or "Clapwiggler". But seriously... may be time to grow up.

[whyterabbyt]

Well... at least it's not called "Clapslutz" or "Clapwiggler". But seriously... may be time to grow up.

Which of these definitions requires the growing up, then? Or perhaps its you that needs to do so.

clap verb
\ ˈklap
\
clapped also clapt; clapping
Definition of clap


transitive verb
1 : to strike (two things, such as two flat, hard surfaces) together so as to produce a sharp percussive noise
2a : to strike (the hands) together repeatedly usually in applause
b : applaud
3 : to strike with the flat of the hand in a friendly way clapped his friend on the shoulder
4 : to place, put, or set especially energetically clap him into jail since I first clapped eyes on it
5 : to improvise or build hastily a hut clapped together from old plywood

[noizebox]

Love the initiative and I will definitely follow the development of CLAP. To me it strikes a good balance between simplicity and functionality. Some things like the necessity to specify ownership of data passed to and from functions feels a little dated, but I necessary to keep a C api I guess.

Host-aware multithreading looks very interesting and it looks like a lot of care has gone into making it thread safe and specifying which function can and cannot be called concurrently and from which thread(s).

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.

[jussi_neuraldsp]

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.

[flechtwerk]

Polyphonic modulation (without resorting to destructive automation) in bitwig with CLAP plugins has me fully sold already.

Absolutely! Finally a seemless integration of u-he plugins into Bitwig, a dream come true.

[antic604]

Polyphonic modulation (without resorting to destructive automation) in bitwig with CLAP plugins has me fully sold already.

Absolutely! Finally a seemless integration of u-he plugins into Bitwig, a dream come true.

Well, I still wouldn't say no to UHe-made native Bitwig device, e.g. a additive / spectral synth

[abique]

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.

Normalization also has its share of problems especially if the plugin wants to increase a parameter range in the future, or when working with enumerated values. Also normalization may bring some confusion: when is a value normalized or not? There are always bugs related to that even if the documentation is absolutely clear.

The parameter will be mapped on a knob using a linear curve. The plugin should choose a convenient domain for it's parameter value/range.

The plugin also has the option to set its min value to 0, and max value to 1 and work within that range

[antic604]

The parameter will be mapped on a knob using a linear curve. The plugin should choose a convenient domain for it's parameter value/range.

That's what I was about to say, but you made it more eloquently

It would be weird for filter cuttof set at e.g. 500Hz with bi-polar modulation of 20% to got both ways by say +/-150Hz - it would sound fine going down, but you'd barely notice it going up.