15 Aug
2009
15 Aug
'09
6:26 p.m.
On Sat, 2009-08-15 at 19:34 +0100, Steve Harris wrote:
On 15 Aug 2009, at 19:25, Steve Harris wrote:
N->M panning. E.g. ambisonic -> *.1. You can not (as you said in your
other email) feasibly do this with several panners, and if you could it
would require a custom GUI to spam multiple plugins to get the job done.
This is simply not realistic, might as well just implement it all in the
host (because the plugin spec has failed). QED.
A mixer such as the ardour mixer requires this (e.g. n strips, each of
which with a configurable number of channels).
A modular would require this to support multi-channel nicely.
Basically, absolutely anything with several multi-channel signal paths
requires this. You couldn't even make a straightforward peak detector/
normaliser with any number of inputs with this restriction.
That it is needed for some value of "needed" is a given. The only
compelling reason to not do it this way would be if it is ACTUALLY so
much more complex it causes problems. I havn't seen any valid argument
for that.
Arguments that plugins can be made in a ridiculous way that hosts
wouldn't understand are irrelevant; even LADSPA can do that. Make 7
unlabeled audio outputs. Voila, useless plugin for anything but manual
wiring. So what? Don't make stupid plugins. A compressor with m
channels and n sidechains (?) where the sidechains are mandatory to
connect is a stupid plugin. The ability to replicate groups isn't
stupid, that plugin is. Reasonable plugins use optional connection to
avoid this, which solves virtually any such case you can make up aside
from ones where the plugin is just inherently not usable in a given
context anyway.
Some hand-waving before I shut up: I don't know why this conversation
seems to assume that the default is to make broken crap that's less
capable than existing competing efforts (merits/drawbacks of AU aside,
power is power). I don't agree with that philosophy at all. Shouldn't
we be trying to do BETTER, if anything? Am I the only one sick of being
stuck with a POS tinkertoy plugin API while the proprietary guys are
clearly miles ahead? Do we really have to have long elaborate arguments
to not do worse than something that came before? At the very least
provide compelling arguments for why. This is silly...
-dr
It's all about making the easy cases easy,
and the complex cases
possible - something I believe in strongly, though I know not everyone
shares that worldview.
I guess a counter argument could be that hosts that can't handle /
don't like the additional complexity could just only offer one degree
of freedom on multiple groups, but I think they'll have a hard job
knowing what group is the principle one to pick.
I was going to shut up, but I'll just add that I am open to having my
mind changed. It seems like a decent idea in theory. If you can walk
me through some realworld cases (not hypothetical, I have this
requirement coming up stuff), and it doesn't seem like a horrible
burden on the user, or host author. I know it's pretty reasonable from
the plugin authors p.o.v.