12 Jan
2003
12 Jan
'03
3:14 a.m.
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:
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?
(one bit LADSPA sidechain proposal below ;)
On Fri, Jan 10, 2003 at 09:21:38AM -0800, Mark Knecht 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.
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 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