9 Aug
2009
9 Aug
'09
7:42 p.m.
On Sun, Aug 09, 2009 at 04:39:01PM -0400, David Robillard wrote:
The port groups extension lets a plugin say things
like "these two
outputs are a stereo pair associated with this particular mono input",
or "this port is a sidechain of this other port", etc. A big problem
with this stuff with LADSPA is that "3 audio outputs" is pretty much
impossible to make sense of (or even 2... the only reason anything
multi-channel works at all is apps make undocumented assumptions). What
ports are what, and what other ports they may correspond to, is all the
information you really need.
Not really, see below.
That said, yeah, replication for anything beyond 1 in
1 out is pretty
unlikely to make sense regardless; unless someone is using 4 outputs as
2 stereo pairs or something like that. Ideally we'll get to the point
where the user can specify they are doing so, so the automatic logic has
more to work with. It's a bit of a weird thing to do anyway, though...
Things like using 4 channels as 2 stereo pairs just shouldn't happen.
Given e.g. Ardour's flexibility in creating strips with any number
of channels there is no need to do such things. Just use 2 stereo
strips in that case, you can link the gains if that is essential (*).
I don't think it makes sense to say whether
"replicating a plugin" makes
sense or not, in general. Not the plugin's problem, in any case, the
plugin should just describe what it's I/O is. How clever the host wants
to be given that information is the host's problem (and depends on quite
a bit of host specific .
For a simple 'mono' plugin there are at least three different
cases to consider whem using it in a 'multichannel' situation;
1. A plugin that does e.g. EQ can be replicated without problem
for multichannel use - you expect the same processing on all
channels, the order doesn't matter, and the channels do not
interact.
2. The situation is already different for e.g. a compressor
or limiter. In that case you would expect the same gain profile
on all channels, probably determined (but not always) by the one
with the highest level. In other words the channels *do* interact.
3. Polyphonic synthesis is again different situation, the voices
would share some control inputs but not all, and many of the voices
could be 'inactive' most of the time - a case that invites some
optimisation.
Clearly at least (2) requires the plugin to be aware of the situation,
and to be designed to handle it. That in turn is possible only if the
plugin interface can represent this case. But also case (1) would
benefit from being aware of the multichannel use: in many cases the
bulk of the work is not the real signal processing but things like
limiting the rate of change of parameters, computing and interpolating
internal parameter values etc. and all of that can be shared if the
plugin standard is designed for it. It's not possible to 'retrofit'
this to existing mono plugins by an extension. And finally, a plugin
that would do the right thing in case (2) would fail if used in case
(3) - it again needs to be aware of being used in this role.
The fourth multichannel case would be things like Ambisonics,
where channels are not equivalent. This can be handled only by
plugins designed for these type of signals. They would probably
use special port types to indicate this. But at the same time a
simple mono EQ could be replicated safely to process even a 16-ch
AMB signal, so that should be possible even if the port types do
not match, and should not require special 'AMB equalisers'.
So the logic is not going to be as simple as just requiring the
same port types. Building this logic on top of a set of optional
extensions would seem to be a nightmare, and that is and always
has been my main objection to this approach.
(*) Ardour allows linking faders in groups, but it does not have
'VCA' faders - which is incredible since these are one of the
most useful feauters of almost all digital (and some analog)
mixers.
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.