Re: [LAD] LADSPA plugins in ardour

On Sun, 2009-08-09 at 23:41 +0200, Fons Adriaensen wrote:
> On Sun, Aug 09, 2009 at 04:39:01PM -0400, David Robillard wrote:
> > 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.

I agree.

> > I don't think it makes sense to say whether "replicating a plugin" makes
> > sense or not, in general.
[...]
> 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.

This is a good point I hadn't thought of. I think I will try to
incorporate this into the port groups extension (it describes how
channels interact, and basically anything else to do with multi-channel,
so it more or less belongs there...)

> 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.

Actually I would say this is exactly the same as situation 2, in terms
of I/O at least (e.g. active/inactive optimisation can be done inside
the (opaque) port contents, or similar, and must be anyway since it's
not necessarily related to dymamic number of channels)

> 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.

This is dramatically more complicated than the simple cases for
replication. It is possible though, and very similar to what's needed
for true polyphony. Different scope though (i.e. involves a bunch of
binary stuff and severe design changes), see above about can of worms.
Most importantly, the information needed for the simple cases is needed
in any case (including ones that have nothing whatsoever to do with
replication... we need to know what the heck our plugins outputs are!).

In short what's needed is ports that can actually hold several buffers,
(where the number of which is dynamically configurable). I've actually
been planning on this one for a while because "hidden" (mixed down)
polyphony sucks severely in a modular, but never thought of it in terms
of replication. Interesting that it applies there too.

> 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.

Currently handled. Not special ports, just collections of normal ports
with appropriate metadata (as it should be).

> 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'.

Yep. That kind of clever is up to the host though (or maybe proxy
plugins if you want to get really fancy, but let's not go there)

> So the logic is not going to be as simple as just requiring the
> same port types.

No, but the information needed to solve the simple ladspa+metadata-esque
case is required anyway, and an orthogonal problem. Solving small
independent problems is good. Trying to solve everything at once fails.
Always. No exceptions.

To be clear, what I mean is: first and foremost, the host must know the
specifics of what ports are what. On top of this, dynamic replication
of ports can be done.

That said, one question comes to mind: are there reasonable cases where
different ports (or groups of ports) need different 'replication
factors'?

> 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.

FUD, nothing more. It would be no more of a nightmare than implementing
it on top of... well, anything else; presumably you mean something
defined in "The LV2 Specification"(TM). No offense but I doubt you
really understand the mechanism judging by this comment. That
"nightmare" (a.k.a. "good design") is exactly what will allow all of the
above to be solved. Proof is in the pudding, as they say.

-----

Aside: Since this seems to be misunderstood frequently, I'll harp on the
point a bit for the list in general (this is an explanation, not an
invitation to argument):

There is absolutely nothing second class, or (necessarily) optional,
about LV2 extensions. A lot of thought has been put in to the
extension/feature concept/mechanism, and it has been carefully designed
specifically so that it is not a "nightmare". Solving the above
problems in "extensions" is not worse than if we were to ram it into the
"core" spec itself. There is nothing inferior about it (wannabe
dictator arguments aside, anyway). There are many things superior about
it, however. The most important is social: nobody on this list needs to
be convinced that having one specification define absolutely everything
is a sure-fire way to have any potentially productive discussion devolve
into endlessly long threads that end up nowhere because nobody can agree
on what's "needed" and what isn't. Extensions are simply a
modularisation of this process: problems can be solved independently by
people who care about those particular problems. You can even work on
actual implementations of things to test them out without any
compatibility problems whatsoever. So, we have nice tidy little
tractable problems, that can feasibly be solved well (see: UNIX). The
end result is: the problems actually, really, can get solved.

Saying this is bad is essentially equivalent to saying design by
committee is good... modularisation like this is such a universally
recognized good design principle it's not really necessary to defend it.

UNIX won, and it's not a coincidence. GMPI has produced almost nothing
tangible of worth whatsoever, while LV2 has produced plenty and is
constantly getting better -- this is not a coincidence either.
Mmm, pudding.

Cheers,

-dr

P.S. To reply to the aside, please change the subject, I don't want to
derail the replication discussion; that is an important unsolved problem

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Aug 10 04:15:06 2009