About CLAP

[ThomasHelzle]

I just had kind of a stupid idea:
Would it technically be possible with CLAP to realize some kind of feedback loop, for example for a reverb or delay effect, where an external effect, like a filter, was inserted in the loop?

Bitwig allows for that in their own factory devices like reverb and delays (inserting plugins into the reverb-chamber/feedback loop).
So far plugins wanting to incorporate other plugins had to scan for them themselves.
Maybe Clap plugins could share the plugins the host already scanned?
I see an extension coming there...

[_gl]

Would it technically be possible with CLAP to realize some kind of feedback loop, for example for a reverb or delay effect, where an external effect, like a filter, was inserted in the loop?

many times I've wanted this, eg. custom in-loop processing for delays. sometimes I build it manually in Reaper using JSFX. last time I tried SynthEdit (a long time ago) it also supported embedding VSTs, that was another way.

[Funkybot's Evil Twin]

In the meantime, BlueCat's Late Replies can host VST plugins in the feedback path.

But my hope is that DAWs and developers will start adding capabilities for CLAP effects to expose more input/output ports for things exactly like that. Might just take some time in case new extensions are required, host support to mature, devs to think up and kind of agree upon an approach, etc. That's my hope at least.

[_gl]

the issue internally is that multi-plugin feedback like that usually causes a buffer's worth of latency. so a built-in method that is delay-compensated would be ideal.

well, technically you could process (say) 1 sample at a time through the plugin chain, but that would be super inefficient. although specifying a fixed feedback buffer size, regardless of the DAW audio buffer, could be useful (that way the latency stays predicable, regardless of what your interface is currently using for its buffer). eg. (say) 32 or 64 samples.

[mystran]

the issue internally is that multi-plugin feedback like that usually causes a buffer's worth of latency. so a built-in method that is delay-compensated would be ideal.

Right. As long as your delay is longer than your blocksize (typically true if we're talking about musical delays), with an internal feedback plugin you can just subtract the latency from the delay time to effectively bring it down to zero. With separate plugins, you'd somehow need to inform the delay plugin about the round-trip time of it's feedback loop to get the same result and the delay plugin to have at least either a separate input or output for the feedback... and while it'd theoretically be possible to spec such a thing into an API, it'd be quite a can of worms (what if a plugin inside a feedback loop also wants to have a plugin inside it's own feedback loop, etc), likely more so than a plugin hosting another plugin inside it's own feedback loop.

[ghettosynth]

Would it technically be possible with CLAP to realize some kind of feedback loop, for example for a reverb or delay effect, where an external effect, like a filter, was inserted in the loop?

many times I've wanted this, eg. custom in-loop processing for delays. sometimes I build it manually in Reaper using JSFX. last time I tried SynthEdit (a long time ago) it also supported embedding VSTs, that was another way.

Just FYI, SynthEdit dropped support for this in the 64 bit version and, AFAIK, have not added it back. I believe Jeff was concerned about people embedding other people's plugins inside of a SynthEdit plugin and distributing it. TBH, I find it annoying because it's a good way to build personal hybrid plugins that work cross host.

[elnn]

The note number not only defines the base pitch, it’s also an id for further modulation (pressure…)

ok, I see.

But each spawned event object could get a unique id (with some parameters initialized, but otherwise absolute values) and other parameters (including receiver specific messages, polyphonic CLAP modulations?) be passed into it?
No name clashing, overlaps allowed, each ID getting its own event stream?

(thus giving complete control over all the elements in an allocated voice, plus allowing ad-hoc couplings of control of separate devices by an event stream…? effectively making voices external and spread over multiple devices)

ahh, but I guess the id would have to be generated and provided by the client and bundled with each message. but the freedom would be radical.

[_gl]

and while it'd theoretically be possible to spec such a thing into an API, it'd be quite a can of worms (what if a plugin inside a feedback loop also wants to have a plugin inside it's own feedback loop, etc), likely more so than a plugin hosting another plugin inside it's own feedback loop.

complex to be sure, but (without thinking it through : ), I suspect there's a solution. the other issue is that if you're not using it for a musical delay, but for a (close as possible) non-latent feedback path (something like a kind of resonance), you don't want the feedback block-size to change, or the audible result may be unpredictable even if the API reported the current feedback latency.

so ideally you would be able to force a fixed feedback block-size, and the DAW would split the actual audio blocks as needed to honour it in all scenarios.

[mystran]

and while it'd theoretically be possible to spec such a thing into an API, it'd be quite a can of worms (what if a plugin inside a feedback loop also wants to have a plugin inside it's own feedback loop, etc), likely more so than a plugin hosting another plugin inside it's own feedback loop.

complex to be sure, but (without thinking it through : )

Often times "thinking it through" is where the problems arrive. That said, CLAP has a really nice extensions mechanism (just pick a name for your extension and you can do pretty much whatever you like; this is how many of the basic features work too) ... so perhaps some day?

[_gl]

Often times "thinking it through" is where the problems arrive.

yeah but it's adjacent to general latency compensation - which is also complex. you can also simplify it, by eg. fixing the feedback path buffer size, and/or not allowing nested feedback paths (a single path should cover most useful scenarios and is better than none).

That said, CLAP has a really nice extensions mechanism (just pick a name for your extension and you can do pretty much whatever you like; this is how many of the basic features work too) ... so perhaps some day?

right nice, you could prototype it inside an open-source DAW.

[mystran]

Often times "thinking it through" is where the problems arrive.

yeah but it's adjacent to general latency compensation - which is also complex.

Actually as long as the signal flow is a directed acyclic graph (ie. cycles if any have been broken), regular latency compensation is really simple. You simply start from the sources (eg. instruments, samples, whatever you have) and accumulate total latency along each edge of the graph, basically the same as if you were processing the graph (ie. process a node once all it's incoming edges have been processed). Whenever a node in the graph has multiple incoming edges (ie. several signals are mixed) you pick the maximum of the incoming values and insert additional delays on the other signal paths.

Now, cycle breaking is basically a matter of a recursive depth-first search. Whenever you enter a node set a boolean flag. Once you've recursed all the out-going edges, clear that flag. If you ever find a node where the flag is already set, the edge forms a cycle. For efficiency after processing some node, you can set a separate flag to skip recursion if that node is entered from a different incoming edge later, so you only need to visit every node once. [edit: upon further thought, I think for better identification of back-edges you need to compute dominators.. not that it's very hard either]

Where it gets a bit hairy is if we try to push the loop back-edge latency to some plugin, because the plugin at the node where the back-edge leads to might not be the one that can compensate. So you'd have to search backwards to try to find another, but then you need to worry about branching signal paths too. From the point of view of graph-theory this is not that complicated, but from the user point of view figuring out when something can or cannot be compensated might become somewhat unintuitive..? Then there's also the fact that if the plugin that can compensate is indeed the node after the loop back-edge, then it'll also need a separate input for the feedback (because it'll now have two incoming signals with different latencies).

edit: Upon thinking about this a bit more, a sensible spec might simply be that (1) the plugin that wants to compensate for loop latency much be the target of the back-edge and (2) must advertise special feedback audio ports that mirror the regular audio ports that allow such feedback. That said, I have a hard time imagining such an extension would be widely implemented as many hosts don't allow feedback to begin with... but then if loops are not natural, I don't know?

[ThomasHelzle]

Bitwig recently started to allow feedback in it's internal routing with 1 sample delay.
And it's factory delay and reverb devices allow for inserting other devices/plugins in the feedback path, so I'd say the standard is in good hands if there is a solution at all

[baconpaul]

The note number not only defines the base pitch, it’s also an id for further modulation (pressure…)

ok, I see.

But each spawned event object could get a unique id (with some parameters initialized, but otherwise absolute values) and other parameters (including receiver specific messages, polyphonic CLAP modulations?) be passed into it?
No name clashing, overlaps allowed, each ID getting its own event stream?

(thus giving complete control over all the elements in an allocated voice, plus allowing ad-hoc couplings of control of separate devices by an event stream…? effectively making voices external and spread over multiple devices)

ahh, but I guess the id would have to be generated and provided by the client and bundled with each message. but the freedom would be radical.

This is entirely possible with CLAP and how Surge implements polyphonic modulation. Basically there's two ways you can address a voice "PCK" (port channel key)" which is tied to a midi key and "note id" which is not. The Host has to provide unique note ids to the synth, and the synth terminates them.

The difference is in cases with long releases where you still want individual modulators per voice with repeated keys and you don't want to rotate channels or want polyphony higher than 16.

It's not easy going from PCK to note id. Surge had some internal structure which made it simpler than other synths. But if you use surge with the modulators your voice lifetime is as long as your release, and a second voice on the same key starts a fresh set of modulators.

[Urs]

Yes. We use PCK for now, but we do have plans to pick up NoteID as an option. The is a major refactoring job of our internal event handling though - as is the introduction of release velocity -, so we probably do both of these things at once.

Let me add that the beauty of the concept is that developers like us can gradually upgrade their paradigms. I see Parameter Modulation and MPE as a stepping stone to Polyphonic Parameter Modulation based on PCK, which in itself is a step towards support for NoteIDs. Once NoteIDs are established *and* Parameter Modulation, one can support NoteExpressions in CLAP, and eventually in VST3 as well. At least, this is how it could work for us.

[baconpaul]

Yes. We use PCK for now, but we do have plans to pick up NoteID as an option. The is a major refactoring job of our internal event handling though - as is the introduction of release velocity -, so we probably do both of these things at once.

Let me add that the beauty of the concept is that developers like us can gradually upgrade their paradigms. I see Parameter Modulation and MPE as a stepping stone to Polyphonic Parameter Modulation based on PCK, which in itself is a step towards support for NoteIDs. Once NoteIDs are established *and* Parameter Modulation, one can support NoteExpressions in CLAP, and eventually in VST3 as well. At least, this is how it could work for us.

Yeah that's how it worked for us in surge. Our voice manager is a bit different from yours so it was more natural to go id than PCK, but once we had that, note expressions were easy as were adapting to the voice stack in a single channel. Its really neat!