[linux-audio-dev] Re: Sidechains, was Re: [linux-audio-announce] [ANN] swh-plugins 0.3.4

[Conrad Parker]

(one bit LADSPA sidechain proposal below ;)

On Fri, Jan 10, 2003 at 09:21:38AM -0800, Mark Knecht wrote:
> 
>    I must admit publicly that within the Linux application environment that
> right now I'm pretty lost on how all these apps are using sidechain
> controls. Often when I admit I'm lost, one or two other lost souls come
> forward and suggest they are a bit lost also.

as there is no way in LADSPA to distinguish between the audio input
ports and the sidechains, there's no way for an app to create a
GUI interface that understands that difference.

what you want is to say "apply this filter to this sound, with these
input parameters and this sidechain", whereas what LADSPA forces is
"load this filter, connect up this sound to these input and these output
ports, connect up this other audio source to this other input port that I
can read is labelled as a sidechain, set the parameters and run". That
style of working might be fine in a modular synth, but is not how people
expect an editor to work. (Heck, even in a modular synth it'd be nice to
know where ramps and LFOs make sense, and where the actual audio should go).

as far as I can remember this was discussed a while ago, along the lines
of proposing that both CONTROL and AUDIO port flags to be set at once for
audio ports used for control purposes. From memory, this was not accepted
because it would break backwards compatability (hosts checking IS_CONTROL
without checking IS_AUDIO would provide a pointer to a single data value,
which the plugin would incorrectly interpret as the start of an array).


Now, how about if we add a SIDECHAIN flag to LADSPA_PortDescriptor (ie.
appropriately use one of the 28 bits still available there):

#define LADSPA_PORT_SIDECHAIN 0x10

#define LADSPA_IS_PORT_SIDECHAIN(x)  ((x) & LADSPA_PORT_SIDECHAIN)


which would leave the semantics of CONTROL and AUDIO flags untouched
(preserving all current functionality) but would allow apps to handle
SIDECHAIN ports differently to non-SIDECHAIN ports.

eg. when applying a filter in an editor, the non-SIDECHAIN ports would be
implied, ie. the data being edited, and the SIDECHAIN ports could be
either offered from a list of open audio clips, or be drawn in by the
user as envelopes.

when using a filter in a modular synth / filter network, everything
would work as before, except perhaps in the GUI the sidechains could be
connected on the side of a module rather than being just another input.

I reckon this would give us what users expect, completely backwards
compatible, without breaking existing plugins or hosts.

Conrad.
www.metadecks.org