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

[S0lo]

@robbert-vdh, Although I have to say I still can't think of an advantage for allowing arbitrary IDs. Contiguous, is pretty much a win-win solution.

[S0lo]

ps. I tried to disable _PER_NOTE_ID in that clap_saw code but bitwig didn't work per-voice when I tried that. Is there some thing else I need to do to try PCK in clap_saw ?

I think (think) you need to put a bitwig device up front which does channel rotation for you. But I've been in note id land since day one so am not *entirely* sure.

Diva works without it. If Diva uses PCK as Urs mentioned, then there must be something else other than _PER_KEY flag that I have to do.

[Urs]

In Diva we do this:

Code: Select all

 param->flags
        = (am_param->isInt() ? CLAP_PARAM_IS_STEPPED : 0)
          | (am_param->isByPass() ? CLAP_PARAM_IS_BYPASS : 0)
          | (am_param->isLocked() ? CLAP_PARAM_IS_READONLY : 0)
          | (am_param->isAutomatable() ? CLAP_PARAM_IS_AUTOMATABLE : 0)
          | (am_param->isHostModulatable() ? CLAP_PARAM_IS_MODULATABLE : 0)
          | (am_param->isHostModulatablePerNote() ? CLAP_PARAM_IS_MODULATABLE_PER_KEY : 0)
          | (am_param->isHostModulatablePerChannel()
                 ? CLAP_PARAM_IS_MODULATABLE_PER_CHANNEL
                 : 0);

Any parameter that is in a voice and that is automatable and that can be reached by our ModMatrix concept (which is pretty much any continuous float-param) returns true for both PerNote and PerChannel.

For note ports, we do this:

Code: Select all

info->supported_dialects
        = CLAP_NOTE_DIALECT_CLAP | CLAP_NOTE_DIALECT_MIDI;
    info->preferred_dialect = CLAP_NOTE_DIALECT_CLAP;

[S0lo]

aha, it's _PER_CHANNEL that I had to add. works!!. Thanks Urs

[Urs]

Hehehe, this would be a bugflaw in Bitwig then... I'd assume that PerNote alone should work just as well...

[mystran]

I think this whole mess is largely caused by the general piano-centric world-view that's the most common the computer music world. My first exposure with computer music was with trackers where you have a number of channels (essentially voices in the musical sense or "voice board" sense, more so than something with a beginning and an end) and you have full control over what channel plays what and the whole notion of "key" is little more than a convenient way to indicate a certain pitch.

Ignoring the quantized handling of time as steps, the biggest "problem" with the tracker-style explicit control of voices though is that it simply doesn't play nice with recording something on a piano-keyboard, because then you'll end up with all your voices (in the musical sense) spread around the channels more or less randomly and this is obviously kinda what happens with a plugin that does automatic voice allocation too.

I don't know. Personally I wouldn't mind just handling the whole voice allocation to the host so that it can be further exposed to the user. You could do this with MIDI channels, but then you're stuck with a limit of 16 (or 15 if you want a global channel) and you'd need some way for a plugin to tell how about the maximum number of voices or alternative for the host to ask the plugin for a certain number of voices.

Perhaps someone should spec a CLAP extension that allows the host and the plugin to negotiate the actual number of voices and then repurposes either the channel or the note_id field to allow for indexing into specific voices directly. That't be great for trackers... but somehow I doubt such an extension would see all that wide adoption.

[Urs]

There's a draft for VoiceInfo

[S0lo]

So after a few tests with PCK. both PORT and CHANNEL are always zero in bitwig. Why is that? The Key is midi note. If I hit the same key with a long release multiple times. Multiple voices do take the same midi note successfully. But modulation is not poly. It will modulate all voices with one mod source.

This is clearly because neither port nor channel are used to differentiate between a mod targeted at this or that voice. This is not the way I understand how MPE works. MPE manipulates the channel.

[Urs]

I guess you'd need an MPE controller to automatically iterate through channels.

(disclaimer: I don't know how Bitwig works)

[S0lo]

Make sense in terms of hardware modulation. But in this case I'm merely using a poly LFO in bitwig, it could just change the channel it self.

BTW, if the notes are not the same. poly mod works perfectly. Even after note release.

[baconpaul]

So after a few tests with PCK. both PORT and CHANNEL are always zero in bitwig. Why is that? The Key is midi note. If I hit the same key with a long release multiple times. Multiple voices do take the same midi note successfully. But modulation is not poly. It will modulate all voices with one mod source.

This is clearly because neither port nor channel are used to differentiate between a mod targeted at this or that voice. This is not the way I understand how MPE works. MPE manipulates the channel.

I think bws has a channel rotation device you would use to front your stream if your device is single channel

[Urs]

(in reply to S0lo) Yes, same here. Which is why we're going to do NoteID eventually, but it's a major surgery in our codebase, so we'll need to do this after the initial release of CLAP versions.

[baconpaul]

@robbert-vdh, Although I have to say I still can't think of an advantage for allowing arbitrary IDs. Contiguous, is pretty much a win-win solution.

Imagine you have a modulated release

Notes 1 2 and 3 start in order. Then note 2 ends.

You then have a non contiguous voice to id

So any assumption of contiguity is a bug waiting to happen.

[baconpaul]

Or imagine you have a device which takes a note and adds one to theee nots an octave and so on up. You need to remap inbound note ids but you don’t know the voice structure or the source or target so you don’t know an upper bound on your contiguous array

[S0lo]

@robbert-vdh, Although I have to say I still can't think of an advantage for allowing arbitrary IDs. Contiguous, is pretty much a win-win solution.

Imagine you have a modulated release

Notes 1 2 and 3 start in order. Then note 2 ends.

The RANGE is contiguous. Not the actual playing notes. You can simply flag ended notes in the array.

For example, a synth states to the host that it can play a maximum of 1000 concurrent notes. The host will abide by that, and use only note_id numbers from 0 to 999. The synth will reserve an array of of 1000 say integers (say note2voice[1000]). initialized to -1, which indicates no notes are being played. A note event from the host comes in at notes_id 20. The synth will choose a voice_number and assigns note2voice[20] = voice_number. Another note comes in at 102. same, note2voice[102] = voice_number2

Now modulation comes in, immediate array look up. No search.

Note off comes in for 20. do note2voice[20]=-1. And so on....