Steve, Sorry for being dense on side-chain issues, but I've shied away from using these specific plugins inside of Ardour since I seem incapable of figuring out on my own how the side chain gets hooked up within that application. Is this an Ardour issue, or am I just missing some simple piece of info that makes it obvious? Nominally I though the term 'sidechain' in a compressor referred to the control signal that drives the VCA. (Or VCA software equivalent.) Many hardware and compressors have a 'sidechain insert point' where you can apply additional processing beyond whatever the RMS/peak detectors in the compressor do themselves. (Or possibly even bypass those and use other signal sources?) Many compressors (both software and hardware) allow you to monitor the sidechain signal in some way to get better control over the compressor. (Waves) 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. Taking Ardour as and example, when I insert an SC2 or SC3, where are the sidechain controls coming from? Inside the compressor (expected) or from some insert that I'm not hooking up correctly (possibly) or elsewhere? Again, sorry for being so dense... Thanks, Mark

(one bit LADSPA sidechain proposal below ;) On Fri, Jan 10, 2003 at 09:21:38AM -0800, Mark Knecht wrote: 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

On Sat, Jan 11, 2003 at 02:10:44 +1100, Conrad Parker wrote: Woah. Lets back up a bit. There is a lot of confustion about the word sidechain. All it actually means is an input that is used as a replacement for the audio from the through path, that is used *for the purposes of control* it is not a control input. What the original guy was talking about (I think) is ladspa plugins that could broadcast its input and other plugins that could receive it, using IPC (possible, but really, really ugly). It would not affect the hosts in any way. His example was for when you have a compressor that needs to take a sidechain input, but your app doesn't allow routing between channels, eg. you need to map your drum output to the sidechain input, but sidechain L+R should be the bassline. You would put a broadcast module in the drum path, set it to transmit, and tell the compressor to receive its sidechain input. What Conrad is talking about is distinguishing audio rate control inputs from control rate control inpputs, which is a valid concern, but unrelated to the original point. - Steve

On Sat, Jan 11, 2003 at 09:56:37AM +0000, Steve Harris wrote: ah, ok, thanks for the clarification. So would it be correct to say that managing a sidechain is totally up to the host, and it's just a matter of how the user can set up routing between plugins? right. erm ... how about it? Conrad. www.metadecks.org