On Wed, 2009-08-12 at 23:29 +0200, Fons Adriaensen wrote:
On Wed, Aug 12, 2009 at 05:04:05PM -0400, David
Robillard wrote:
On Wed, 2009-08-12 at 23:00 +0200, Fons
Adriaensen wrote:
That is
the essential difference between a plugin being used in
a multichannel stream and one being used for polyphonic synthesis,
where the cutoff frequency could be a per-voice envelope.
Provided the plugin can do both, it is the *host* that has to make
clear what's required.
++
Though in the latter case, it's probably best to just instantiate the
thing twice as hosts currently do (and will likely need to implement
regardless).
Yes, the 'polyphonic' case is the only one where just replicating
the complete plugin would make sense (*). But even in that case there
could be some shared parameters - maybe we just have to accept the
cost of them being evaluated N times.
OTOH, there is a big difference between e.g. a lowpass filter in a
mixer strip and one being used as part of synthesiser patch.
In the first case the cutoff parameter would be static 99.999% of
the time, while in the other it's bound to be very dynamic. In both
cases you'd want 'zipper free' performance, but the tradeoffs would
be quite different.
(Aside: this reminds me a bit of a number thing that comes up often in
design stuff: a "special" 0 is fine, a "special" 1 is fine, but a
"special" 2 or anything else is very likely bad (because it should be a
generic "many"))
Here we have 1 (no replication) or many (replicate to n, or maybe a
multiple of m if we need that). The problem being, sometimes we want
group A (audio) to replicate and C (controls) to not, and sometimes we
want them both to. They can't be truly independent though, because they
need to match if they're both replicated.
Regardless we need replication to happen on a "group of ports" level
(rather than a whole plugin level), so given that, how about:
Allow one group of ports to have either no replication, or the same
replication count as another group of ports. Obvious example being,
controls tend to stick to 1, audio tends to get replicated, but we may
want to replicate the controls to match audio. So, a single plugin
could do all of the above cases in a single instance, if the author
wants to do it that way.
Deals with all the possible cases (?) but really simple: basically one
property to say "if I'm replicated, I must match this other group's
count". The lazy host can just not replicate them at all without any
negative consequences
Cheers,
-dr