(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
