Re: [LAD] Lv2 port replication [for dummies]

On 15 Aug 2009, at 00:36, David Robillard wrote:

> On Fri, 2009-08-14 at 23:41 +0100, Steve Harris wrote:
>> On 14 Aug 2009, at 21:47, David Robillard wrote:
>>>>
>>>> The host can do it automatically, obviously.
>>>
>>> The host can do it automatically with the C multiplication
>>> operator as
>>> well, obviously.
>>
>> True, but irrelevant.
>>
>> If you have N channels feeding a panner with 5.1 outs v's N channels
>> feeding 2.1 outs, I very much doubt that you want that to be a single
>> plugin.
>
> It has to be, because the N channels may be a specific type of N
> channels. 7.1, say, or ambisonic.

Right, so that makes it a bad example of why you need this variables
cardinality thing.

>> Ambisonics may well be different, but my understanding is that
>> there's
>> a selection of different formats, and you don't go between them by
>> just adding or removing channels.
>
> Exactly. You can't use N 1->M panners to do an N->M panning job.
> This
> is true of *.1 as well as ambisonics.

Nope, but you can use N 1->c panners.

> In general, this is just the ugly head of a huge shortcoming LAD stuff
> has always had, the LADSPA and JACK assumption that just having a
> "bunch
> of channels" is not good enough. If you think about it, it's actually
> pretty true to say that the LAD/Jack/LADSPA stack doesn't even
> correctly support stereo! We get by with undocumented assumptions
> about
> port order and such. I'd have a hard time saying anything beyond
> stereo
> is reasonably supported at all. Sure, you can carefully wire up
> everything manually, but the shortcomings there are obvious.

Sure, that's why we have annotated groups in LV2.

>>> Surround panning is not trivial, and not a small amount of code. It
>>> is
>>> exactly the sort of thing you'd want a plugin for.
>>
>> Agreed. I still don't know how you'd make it work though.
>
> I don't think it's really that bad, or much worse. Instead of the API
> allowing the host to say "plugin, you have N channels", the API allows
> the host to say "plugin, this group has N channels".

Yeah, but there's no easy way for the host to intuit the semantics of
that. It would offer a dialogue to the user, but yuk!

> On the data side of things, all we really need is the before discussed
> predicates to say this group's count matches that group's count, and a
> predicate to list supported 'stream types'.

I've still not seen a realistic usecase.

> I could be missing something? It doesn't seem that much more
> complicated.

In theory, it's not, but the practical aim of doing something useful
and generic with it is a significant challenge. You could certainly
spec it out to handle some particular case (say panners), with a lot
of effort, but I think that's just a bad idea.

> It /could/ be quite a bit more complicated if, say, the host set the
> input counts and the plugin could dynamically say pretty much anything
> about the output counts, but I agree /that/ would probably be going
> too
> far. I don't think that is really needed, being able to say this
> group
> and that group are equivalent seems to take care of anything even
> remotely feasible in the short to medium term. Equivalence is pretty
> easy to deal with, and the simple plugins (that are the arguments
> for a
> global count) would only have 1 input and 1 output group that would
> match anyway. The simple plugin case is pretty much as easy to deal
> with as it is if the spec only supported a single count.
>
> Common host logic would be something like:
>
> - I have a stereo stream here for this plugin
> - Does this plugin support stereo input?
> - If yes, then set the plugin inputs to stereo, and check what
> outputs
> are matched (trivial), and set those to stereo too
> - If no, this plugin doesn't work here (defer to user or just reject)

But how does the host tell N-ary stereo from N-ary mono channels - eg.
a stereo/quadraphonic/etc. image width modifying plugin. You'd need to
map particular group cardinalities to particular semantics, and that
still doesn't let you handle both LR and MS for eg. Or different
formats of ambisonics.

> There are annoying cases that could crop up, such as the outputs
> already
> being connected to something non-stereo, but these would have to be
> dealt with either way. It seems to be having the count at the group
> level doesn't really complicate anything much.

I don't agree. I think if you only have one degree of flexibility then
the semantics are a lot clearer for all involved.

Another example:

Think of a N-channel compressor (one of the key usecases in my mind,
it's something that LADSPA and LV2 just don't handle at the moment,
outside of a modular synth).

If you also allow M-channel sidechains (perfectly reasonable usecase,
and something you might imagine was easy) then you get into a world of
hurt. The host needs to ask the user how many sidechains they want v's
how many audio channels at instantiation time, and they need to figure
out how to hook up the sidechains in a sensible way. This is not
something plugin hosts are used to dealing with, and I suspect it will
make the plugin application UI very annoying for the common, simple
cases.

OTOH, if you don't allow multiple cardinalities, then the N-channel, M-
sidechain usecase becomes more annoying (you have to run the sidechain
signals though a mixer first), but the common, simple case requires no
extra interaction from the user than their used to. The host can
(safely) make the assumption that the tagged, N-channel audio ports
should be connected to however many channels are in the strip the
plugin is being applied to.

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'm packing to go off on holiday for two weeks now, but I hope I've
been able to make my viewpoint clearer.

- Steve
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Aug 16 00:15:01 2009