On Sat, 2009-08-15 at 19:34 +0100, Steve Harris wrote: > On 15 Aug 2009, at 19:25, Steve Harris wrote: > > 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.
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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
