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

[mystran]

So this also entails that after the modulation is done. Either the host or the plug-in should set the mod amount to zero, otherwise the final value is destructive. Who is responsible of that?

I'd imagine you zero global modulation on reset() and per-voice modulation when you start a new voice (or end the previous in case there's a distinction).

Thing is, with a modular synth, all voices are always ON and free running. It's the VCAs that close the sound. Plus, figuring out when a sound actually ends can be very hard to impossible with complex patches and feedback loops, it might never end.

I could end the mod when a new note comes in though, but haven't thought of the implication yet.

This is sort of why I was talking above about how it would be so much more convenient if the plugin could tell the host how many voices there are and the host would just allocate notes to those voices directly and none of this modulation stuff was related to notes, but rather directly to voices.

Interestingly, I was just thinking about another related issue: if one is multi-threading voices, then it'd be much more efficient to just dispatch the whole block once and then do whatever buffer splitting needs to be done locally in each voice. Even if in practice they all split at the same points, that's a lot less task dispatch overhead and you could just hand over the whole event list to all the voices directly and let each of them skip over the stuff they don't care about and then potentially split in the voices themselves...

...except this doesn't quite work, because we still need to go through the events globally first in order to find the note-on messages and allocate voices.. and then you have the same voice potentially processing different notes for different parts of the buffer, so if you want them to split the buffer internally, you probably have to build a separate event list for each voice?

[S0lo]

This is sort of why I was talking above about how it would be so much more convenient if the plugin could tell the host how many voices there are and the host would just allocate notes to those voices directly and none of this modulation stuff was related to notes, but rather directly to voices

I think Urs is working on something for voice id

There's a draft for VoiceInfo

Though I still think there is essential value in providing note_id too. Talked about it earlier. viewtopic.php?p=8472270#p8472270

Here is another idea, when note_id is used, we could allow the plugin to send back a message to the host that informs it of the chosen voice_id the plugin wants. This way the host can use the voice_id in subsequent mod events if it wants. This keeps the control/choice in the hands of the plugin but yet allow the host to use it.

[baconpaul]

So this also entails that after the modulation is done. Either the host or the plug-in should set the mod amount to zero, otherwise the final value is destructive. Who is responsible of that?

I'd imagine you zero global modulation on reset() and per-voice modulation when you start a new voice (or end the previous in case there's a distinction).

Thing is, with a modular synth, all voices are always ON and free running. It's the VCAs that close the sound. Plus, figuring out when a sound actually ends can be very hard to impossible with complex patches and feedback loops, it might never end.

I could end the mod when a new note comes in though, but haven't thought of the implication yet.

Yeah but hardware Modular synths are also logically monophonic right? There’s a signal path which is going for a long time. You can modulate a cv value but not polyphonically. (Of course it’s your Modular is large enough to have 2 completely disconnected subgraphs you are duophnic etc…)

But if you had a software Modular which hosted a clap synth and converted midi to gates and triggers it’s pretty obvious what to do and where the voices are.

[baconpaul]

Here is another idea, when note_id is used, we could allow the plugin to send back a message to the host that informs it of the chosen voice_id the plugin wants. This way the host can use the voice_id in subsequent mod events if it wants. This keeps the control/choice in the hands of the plugin but yet allow the host to use it.

This was my original proposal around clap 0.21 and I was very excited about it

Unfortunately if you do this you can never block process in your daw. A daw would have to interrupt its block when a new voice is arrived to start modulators and voice ids can arrive anywhere

Moving every daw in the world to per sample vs event stream processing seemed impractical so we instead decided that the host was required to issue note ids when it undertakes a note on event since it can then coincidentally start modulation streams and set up the entire block a priori

[mystran]

Here is another idea, when note_id is used, we could allow the plugin to send back a message to the host that informs it of the chosen voice_id the plugin wants. This way the host can use the voice_id in subsequent mod events if it wants. This keeps the control/choice in the hands of the plugin but yet allow the host to use it.

This does not work. The problem is that you'd still have to handle note_id anyway, because the host can send note-on + modulation relevant to that note in the same event list to the same process() call. This is why it's the host that must choose the ID.

The reason it'd be nice if the host could allocate the voice directly is because then you could take the incoming list of event and split it by voice directly... where as with note_id (or PCK, whatever) you first have to go through the list and figure out where the note-on messages might be and then you have half a buffer when voice N is note K and other half where the same voice N is note J.. which .. is annoying, because now you need to do a lot more book keeping... and you still can't do tracker-level user control over what voice plays what unless you have every voice on a different port (which I guess is also one option).

[S0lo]

Yeah but hardware Modular synths are also logically monophonic right? There’s a signal path which is going for a long time. You can modulate a cv value but not polyphonically. (Of course it’s your Modular is large enough to have 2 completely disconnected subgraphs you are duophnic etc…)

Yeah but not in my case, I automatically produce identical voices behind the scene. It can be complelty polyphonic, duophnic, monophonic, para-phonic or what ever you want. If interested, here are the details: http://www.solostuff.net/polyphony-in-solorack/

[S0lo]

Here is another idea, when note_id is used, we could allow the plugin to send back a message to the host that informs it of the chosen voice_id the plugin wants. This way the host can use the voice_id in subsequent mod events if it wants. This keeps the control/choice in the hands of the plugin but yet allow the host to use it.

This was my original proposal around clap 0.21 and I was very excited about it

Unfortunately if you do this you can never block process in your daw. A daw would have to interrupt its block when a new voice is arrived to start modulators and voice ids can arrive anywhere

Moving every daw in the world to per sample vs event stream processing seemed impractical so we instead decided that the host was required to issue note ids when it undertakes a note on event since it can then coincidentally start modulation streams and set up the entire block a priori

I agree, there has to be at least a 1 block delay until the host gets the voice_id. Which is not ideal. But again, I'm not sure I understand your point correctly. I'll need to think of it and read it again

[S0lo]

This does not work. The problem is that you'd still have to handle note_id anyway, because the host can send note-on + modulation relevant to that note in the same event list to the same process() call. This is why it's the host that must choose the ID.

I agree. But it will work in one of the subsequent proccess() calls once the host gets the message. There is no grantee as to the delay off-course. Not great. But will work in cases where the mod it self is delayed.

Basically, the host can keep using the note_id until it gets the voice_id message. The plugin will still have to handle both. Again, Not great.

[mystran]

Basically, the host can keep using the note_id until it gets the voice_id message. The plugin will still have to handle both. Again, Not great.

So what's the point of having voice_id at all then? It's not a piece of information that is terribly useful for a host when allocated by the plugin?

[baconpaul]

Here is another idea, when note_id is used, we could allow the plugin to send back a message to the host that informs it of the chosen voice_id the plugin wants. This way the host can use the voice_id in subsequent mod events if it wants. This keeps the control/choice in the hands of the plugin but yet allow the host to use it.

This was my original proposal around clap 0.21 and I was very excited about it

Unfortunately if you do this you can never block process in your daw. A daw would have to interrupt its block when a new voice is arrived to start modulators and voice ids can arrive anywhere

Moving every daw in the world to per sample vs event stream processing seemed impractical so we instead decided that the host was required to issue note ids when it undertakes a note on event since it can then coincidentally start modulation streams and set up the entire block a priori

I agree, there has to be at least a 1 block delay until the host gets the voice_id. Which is not ideal. But again, I'm not sure I understand your point correctly. I'll need to think of it and read it again

Right a one block delay
If your block is 256 that means your amortized voice on envelope will be 128 samples late
That is way too much

[baconpaul]

Yeah but hardware Modular synths are also logically monophonic right? There’s a signal path which is going for a long time. You can modulate a cv value but not polyphonically. (Of course it’s your Modular is large enough to have 2 completely disconnected subgraphs you are duophnic etc…)

Yeah but not in my case, I automatically produce identical voices behind the scene. It can be complelty polyphonic, duophnic, monophonic, para-phonic or what ever you want. If interested, here are the details: http://www.solostuff.net/polyphony-in-solorack/

Right if you are making polyphony in hardware in audio and not in cv then you have a very hard time detecting voice end. Or really even defining a voice at all.

[S0lo]

Basically, the host can keep using the note_id until it gets the voice_id message. The plugin will still have to handle both. Again, Not great.

So what's the point of having voice_id at all then? It's not a piece of information that is terribly useful for a host when allocated by the plugin?

Two reasons,

1. If two or more note_id map to the same voice_id, the host will know the plugin is stacking/overlaping. That is, playing that voice mono-phonically with some sort of note priority (assuming both notes haven't ended yet). This can help the host optimize the mod. So it doesn't need to create a separate mod for each note_id. ie. One mod per voice.

2. The plugin doesn't have to search for the voice_id

[mystran]

Basically, the host can keep using the note_id until it gets the voice_id message. The plugin will still have to handle both. Again, Not great.

So what's the point of having voice_id at all then? It's not a piece of information that is terribly useful for a host when allocated by the plugin?

Two reasons,

1. If two or more note_id map to the same voice_id, the host will know the plugin is stacking/overlaping. That is, playing that voice mono-phonically with some sort of note priority (assuming both notes haven't ended yet). This can help the host optimize the mod. So it doesn't need to create a separate mod for each note_id. ie. One mod per voice.

Yet.. there's already the NOTE_END message for this purpose?

2. The plugin doesn't have to search for the voice_id

Oh come on... it's really not that bad...

[S0lo]

Right a one block delay
If your block is 256 that means your amortized voice on envelope will be 128 samples late
That is way too much

Right, let me ask a question. Is the voice_id completely useless from a host perspective, if it arrives late ?

[S0lo]

1. If two or more note_id map to the same voice_id, the host will know the plugin is stacking/overlaping. That is, playing that voice mono-phonically with some sort of note priority (assuming both notes haven't ended yet). This can help the host optimize the mod. So it doesn't need to create a separate mod for each note_id. ie. One mod per voice.

Yet.. there's already the NOTE_END message for this purpose?

Not sure I follow, the two or more notes clearly haven't ended yet, Thats the reason the host figured the voice is stacking notes on one voice.

2. The plugin doesn't have to search for the voice_id

Oh come on... it's really not that bad...

Well, yeah. Unless you have a barrage of voices and modulators PER VOICES. Ok, it's arguable