CLAP: The New Audio Plug-in Standard (by U-he, Bitwig and others)

[Architeuthis]

I don't understand your post completely, you might be not verbose enough.

One thing I didn't understand is: Can my pluck envelope modulate precisely a parameter on a synth? Or is there a limit on samplerate or value changes per second?

What if we have a 16 channel polyphony midi controller, you only need one connection, because all 16 midi channels can be controlled from that one input. A note triggers the midi channel 1 and the midi controller sends a trigger signal, and the synth outputs a single voice audio, and then when another note is triggered, the midi controller outputs on midi channel 2. The synth then adds another voice.

Hmm ok then the problem is how do you do per-voice modulation. Actually, you can do a lot with monophony. There are times when I exclusively compose in monophony, so I still think my idea is good even with all the limitations considered. Yeah you could design a synth with 16 inputs to all its parameters or if the limit is 16 then what if you employed some crazy FM or AM interpreter like radio to then send various signals to the 16 voices using only one input?

Edit: Or... what if a synth could take in pre-defined signals that it then either loops or triggers once? What I mean is: Have the synth record the output of a module then it has that signal to do whatever with, including per-voice modulation. Yes, this would also pose a big limitation, but still could be quite useful.

[teilo]

What if we have a 16 channel polyphony midi controller, you only need one connection, because all 16 midi channels can be controlled from that one input. A note triggers the midi channel 1 and the midi controller sends a trigger signal, and the synth outputs a single voice audio, and then when another note is triggered, the midi controller outputs on midi channel 2. The synth then adds another voice.

You just described MPE. That's the workaround for polyphonic expression in MIDI 1.0. We have far better options in CLAP which will be nicely compatible with MIDI 2.0, which does not need the MPE hack to get poly modulation.

But MIDI is not the issue. MIDI is input. DAW modulation is input. We already have poly modulation on the input side. But audio output is summed to one or more channels. All note information is lost. As noted, you would need a completely new concept where every single voice is output to its own channel. This would not be anything like any current plugin architecture. With such an architecture, there could be no internal instrument FX, because most synth effects are not polyphonic due to the tremendous CPU load. Every plugin would have to be completely re-written around some new protocol. I don't see it happening.

[Architeuthis]

I don't see it happening.

P.S. I'm not proposing additions to CLAP. My posts are merely thought experiments.

[Architeuthis]

Can one make CLAP plugins with C++ at this time or is there conversions or wrappers that need to be done?

[Urs]

Can one make CLAP plugins with C++ at this time or is there conversions or wrappers that need to be done?

CLAP is a pure C ABI. One can bind it to pretty much any programming language. One such binding is the C++ Glue Layer in CLAP's "helpers" repository:

https://github.com/free-audio/clap-helpers/

It contains a C++ class (plugin.hh) that you can derive from directly and overwrite whatever CLAP functions and extensions you want. Several examples are using this already, including the "official" CLAP example plug-ins.

[S0lo]

I couldn't find this. Is there a way to query the host for the current tempo? just like in getTimeInfo() in VST. Or do we have to wait for an event from the host.

[mystran]

I couldn't find this. Is there a way to query the host for the current tempo? just like in getTimeInfo() in VST. Or do we have to wait for an event from the host.

Process structure has a field for transport event (and additional events can be sent).

[Architeuthis]

Is it possible someone could help me get CLAP header to compile in Visual Studio command prompt project? That way, I'd have access to realtime debugging and hot reloading. Then also everyone could benefit. a ready-to-go visual studio project would probably benefit CLAP for adoption, I guess most people would want C++, but I'm doing C, so we could just have both.

p.s. this isn't exactly original or latest code, it's past clap 1.0 release with all the headers and the .c put into a single file, just because that was easier to make use of. But I can just redownload the latest code as well.

[Jeff McClintock]

As noted, you would need a completely new concept where every single voice is output to its own channel. This would not be anything like any current plugin architecture. With such an architecture, there could be no internal instrument FX, because most synth effects are not polyphonic due to the tremendous CPU load. Every plugin would have to be completely re-written around some new protocol. I don't see it happening.

One thing that can be done, is to spawn multiple instances of the plugin - one for each voice.
So rather than a super-complicated plugin API to handle polyphony, make one simple plugin and have the DAW spawn several copies of it.

As you point out, only some plugins (e.g. Oscs and filters) should be polyphonic. An effect plugin, you would typically NOT make polyphonic, just sum all the voices beforehand, and feed the combined signal into a distinct effect plugin.
For e.g. here is a gain plugin, where the DAW has spawned 9 copies, one to handle each voice. Each green 'LED' represents a voice that is playing a note through one instance of the 'AGain' plugin.



One requirement for this technique is that in this situation you don't really want 9 copies of a plugin's GUI open, (all the instances have the same settings). So we open ONE copy of the GUI, and connect it to ALL the instances.
Perhaps CLAP 2.0 could support this kind of scenario? i.e. separated GUI/Processor classes. (VST3 does this by having two flavors of VST3 plugin: single-component like CLAP, but also a dual-component option, like GMPI)

[Urs]

Well, as GMPI has a requirement for polyphonic modulation, I don't think one needs to re-interpret its requirement for separated GUI/DSP as a means to accomplish exactly that. It wouldn't because separation does not equal N:M relationships.

GUI and DSP have been separated since the early days of plug-in formats, and it still is in CLAP. Few formats additionally allow the UI to live in a different process, which is based, among other things, on the (naive?) assumption that some time in the future plug-ins would need to be distributed in a network. This IMHO was one of the worst conceptual errors in plug-in design: It tries to accomplish something that is not needed and which at the same time ignores the reality of plug-in engineering which thrives on fast, latency free communication between UI and DSP.

And yet, the Qt-based CLAP example plug-ins run the UI in a separate process. How about that!

(latter was done to show that if anybody wanted to, they could. Without making the plug-in API intolerably complicated)

[S0lo]

One thing that can be done, is to spawn multiple instances of the plugin - one for each voice.
So rather than a super-complicated plugin API to handle polyphony, make one simple plugin and have the DAW spawn several copies of it.

We actually do that in an internal modular API. Albeit per module, instead of per plugin.

Still, I don’t think that a plug-in API should totally depend on that for polyphony. Since that’s more like a host feature. (Not saying off course that you implied such dependency)

[Urs]

Is it possible someone could help me get CLAP header to compile in Visual Studio command prompt project?

I can't help you with that, but if you get to accomplish it, it would be great if you submitted this as a Gist or something so everyone can benefit from it!

[S0lo]

In the future, it might help if some one drops a few lines on how to install that Qt dependency. When I tried it, the installer said something like 6.7GB required!!. I stoped it. Thinking let’s try the other options like surge saw, and clap_template before going into this. They worked, and so I never got to build those examples.

[baconpaul]

Is it possible someone could help me get CLAP header to compile in Visual Studio command prompt project? That way, I'd have access to realtime debugging and hot reloading. Then also everyone could benefit. a ready-to-go visual studio project would probably benefit CLAP for adoption, I guess most people would want C++, but I'm doing C, so we could just have both.

p.s. this isn't exactly original or latest code, it's past clap 1.0 release with all the headers and the .c put into a single file, just because that was easier to make use of. But I can just redownload the latest code as well.

hmmm make sure you are on latest - that problem was around in the 0.2* versions but we build the 1.* versions with msvc regularly now. So make sure your single file conversion actually has the latest of every file.

[baconpaul]

Is it possible someone could help me get CLAP header to compile in Visual Studio command prompt project? That way, I'd have access to realtime debugging and hot reloading. Then also everyone could benefit. a ready-to-go visual studio project would probably benefit CLAP for adoption, I guess most people would want C++, but I'm doing C, so we could just have both.

p.s. this isn't exactly original or latest code, it's past clap 1.0 release with all the headers and the .c put into a single file, just because that was easier to make use of. But I can just redownload the latest code as well.

Oh sorry the problem is you are using `CLAP_VERSION_INIT` rather than `CLAP_VERSION` in your description. Just fix that and you will be fine.