Clap Plugin Format

[Urs]

Urs, just be frank and tell everybody that the main reason of CLAP is to have an excuse to procrastinate Zebra 3 for at least another 3 years

Three weeks, I hope...

The only reason I'm getting super involved in CLAP currently is the overwhelming feedback from the developer community, and polyphonic parameter modulation, which I had to write some extension to our codebase for.

Once the dust settles, I'll be back on Z3!

[Tj Shredder]

And that will certainly benefit Z3…

[ThomasHelzle]

Odin 2 joins the Clap family and works in Bitwig 4.3 beta:
https://thewavewarden.com/odin2



viewtopic.php?p=8451121#p8451121

[Urs]

Dexed should have builds, too.

[koalaboy]

Would CLAP - theoretically - through extensions, allow a plugin to offer parts of it's functionality as modulators within Bitwig, assuming they also adopted the capability ?

So, let's say I have... I dunno.. Zebra Hypothetically, could it be possible to have one of the MSEGs exposed as a modulator within the bitwig device, such that it could be used on other devices ?

I'm trying to think through the potential of extensions, if forward-thinking plugin devs and hosts were to collaborate in cool ways

(And I understand that anything like this could be a whole lot of work, even if possible, and not necessarily something that would make sense to either party, but I'm just wondering about how 'endless' the possibilities are, especially within Bitwig that already opens many doors)

[Urs]

I don't think CLAP plug-ins will go into the Grid a that is rocket science and space technology.

But yes, there are proposals for extensions that let plug-ins modulate other plug-ins directly. It remains to be seen how viable this is. In theory it's already possible to make a CLAP plug-In that poses as alternative GUI for another CLAP plug-in.

And of course, CLAP already allows plug-ins to send MIDI 1.0/MPE/2.0 to the next plug-in.

So yes, I think there'll be a lot of potential for such kind of things, but we also have to evaluate just how much trouble this could mean: If any such thing compromises simplicity and stability, it will probably be rejected.

[koalaboy]

Thanks, Urs. It wasn't necessarily for the grid - I was just using examples.

One common wish I (and I suspect many others) have, is for a DAW to be able to directly reference modulation (CV) outputs of a plugin, similar to Reason in some respects but exposed more formally.

Imagine, if you will, all of the existing step sequencer VST plugins, and how they need to jump through hoops to midi-map the output (other than note information), or some other mechanism to expose the modulation changes.

In an ideal world, anything else in the track chain would be able to just receive the input directly.

In the case of Bitwig, having 'output modulation' sockets at the end of a plugin device, would mean, in this example, that something like StepicVST could expose the output of each automation lane as an 'output modulator' instead of having to use Midi CCs, or Map via some other mechanism, and then these could be connected within the DAW like any other.

If a plugin can be used within a DAW in the same way a modular component is used within a modular rack, it opens up so many other possibities (again, I realise this is what Reason does but mostly in a closed garden).

Bitwig is the best solution that I have found to achieve real flexibility so far, and I'm hopeful that the ecosystem could grow again to enable yet more diversity and flexibility with how all of the products, DAWs and plugins, can interoperate.

[] Peter:H []

Thanks, Urs. It wasn't necessarily for the grid - I was just using examples.

One common wish I (and I suspect many others) have, is for a DAW to be able to directly reference modulation (CV) outputs of a plugin, similar to Reason in some respects but exposed more formally.

Imagine, if you will, all of the existing step sequencer VST plugins, and how they need to jump through hoops to midi-map the output (other than note information), or some other mechanism to expose the modulation changes.

In an ideal world, anything else in the track chain would be able to just receive the input directly.

In the case of Bitwig, having 'output modulation' sockets at the end of a plugin device, would mean, in this example, that something like StepicVST could expose the output of each automation lane as an 'output modulator' instead of having to use Midi CCs, or Map via some other mechanism, and then these could be connected within the DAW like any other.

If a plugin can be used within a DAW in the same way a modular component is used within a modular rack, it opens up so many other possibities (again, I realise this is what Reason does but mostly in a closed garden).

Bitwig is the best solution that I have found to achieve real flexibility so far, and I'm hopeful that the ecosystem could grow again to enable yet more diversity and flexibility with how all of the products, DAWs and plugins, can interoperate.

Proposed something similar on the Surge XT Clap discord, though a bit more generic.
I proposed that plug-ins can themselves expose "values" of arbitrary type (producers) which can be consumed by other plugins everywhere in the daw.
Use Case 1: I would love to be able to have chords on a single chord track of a Song. A "producer plugin" sits in the chord track takes the chords and produces the respective frequency values.
A arbitrary number of consumer plugin anywhere in the DAW can consume the frequencies and control EQ bands with it for instance...
Use Case 2: I would love to habe somehow modeling a "song tension" which can easily be consumed everywhere in the DAW. Yes, I know Bitwig can do this already. But other DAWs might not. If CLAP is (really) clever enough it would open a wide range of possibilities...

[Urs]

Yes, CLAP plug-in can expose audio channels as "CV". We certainly hope that this will lead to interesting new concepts, and a few companies who we've been talking to would be a perfect fit for those kinds of concepts.

[u-u-u]

Yes, CLAP plug-in can expose audio channels as "CV". We certainly hope that this will lead to interesting new concepts, and a few companies who we've been talking to would be a perfect fit for those kinds of concepts.

So you got the propellerheads?!

[u-u-u]

Does exposing audio channels as cv also mean that e.g. Bitwig could show them as modulators whereas Reason could show them as rack devices' CV outputs?

[Urs]

Yes, CLAP plug-in can expose audio channels as "CV". We certainly hope that this will lead to interesting new concepts, and a few companies who we've been talking to would be a perfect fit for those kinds of concepts.

So you got the propellerheads?!

We could not reach them. Tried a few contacts.

Does exposing audio channels as cv also mean that e.g. Bitwig could show them as modulators whereas Reason could show them as rack devices' CV outputs?

I think that really depends on the DAW concept. The CV option is meant for integration with hardware, but it can also of course be used for high resolution plug-in -> plug-in modulation.

For polyphonic modulations it's probably best to use the MIDI approach for now.

[SLiC]

VCV Rack sounds like it could benefit from CLAP in its VST Host….

[Devicemeister]

I'm kind of excited about CLAP now. I think CLAP and Stepic could be a good match and I'm going to dive into it very soon to see what's possible. Hopefully there will be more hosts adapting to it. I have my doubts about the big, established ones. But I do not care. I have fallen in love with Bitwig for quite some time and will look into CLAP for that reason alone. Big thanks also to Baconpaul who pointed me to their JUCE extension and making it open-source available!

[Urs]

VCV Rack sounds like it could benefit from CLAP in its VST Host….

They do