On Sat, Jan 11, 2003 at 09:56:37AM +0000, Steve Harris wrote: > On Sat, Jan 11, 2003 at 02:10:44 +1100, Conrad Parker wrote: > > (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. > > 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.
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? > > 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. right. erm ... how about it? Conrad. www.metadecks.org
