easyeffects
easyeffects copied to clipboard
wwmm
Feature request: proper `External Sidechain` support
Certain effects now support using external sidechain input. That is great, but unfortunately, the implementation is artificially restricted: only the hardware inputs can be selected. This is plain wrong.
For example, i'd like to auto-level the input, and then gate it. Naturally, gating something that has been auto-levelled is not going to work well, but hurray, thankfully the gating isn't necessarily driven by the signal-to-be-gated, but by the sidechain input, which is by default the signal-to-be-gated.
If you open qpwgraph / helvum patchbay with some native LSP effect being loaded, you'll see two inputs:
I did not understand what you want. Would it be to be able to select an arbitrary filter port as the sidechain input source? This would be more on the scope of a general purpose host. Our pipeline management code isn't well suited for this kind of task. In one way or another there will be some restriction over the ports that can be selected.
Would it be to be able to select an arbitrary filter port as the sidechain input source? This would be more on the scope of a general purpose host.
I understand that having a fully arbitrary pipe flow is unlikely to be in EE's scope.
Currently, Sidechain: internal means that the input is both processed and used to guide the processing,
while Sidechain: external (device XYZ) uses the input from device XYZ to guide the processing of the input.
What i would hope for, is to be able to select the output of some effect,
as the Sidechain source of the effect that sits somewhere later in the pipeline.
I.e.:
But NOT: (limiter does not process the actual audio flow, only sidechain)
I see. I think it is doable. But it is something that should be done after support for multiple filters instances is implemented so we do not work twice. I can see "simple ways" to implement this that would totally fail once multiple instances are in place.
@LebedevRI I have updated our master branch with an initial implementation for this. Now it has to be tested.
Filters from the speakers pipeline are shown with an speakers icon and the ones from the microphone pipeline are shown with a mic icon. As far as I could see things are fine when a filter output is selected as the sidechain input. But I have noticed that PipeWire can change latency wildly when the sidechain input is linked to a filter that is in a different pipeline. At least my computer was able to handle the very lower latency PipeWire decided to use in this situation. I am not sure about others.