[LAD] Multi-Channel channel order

[David Robillard]

On Fri, 2009-08-14 at 19:29 +0200, Fons Adriaensen wrote:
> On Fri, Aug 14, 2009 at 12:36:36PM -0400, David Robillard wrote:
> 
> > Is there any existing 'standard' for the order of channels for
> > higher-than-stereo multi-channel streams?
> > 
> > ...
> > 
> > For example, for discrete non-interleaved 5.1 (using a full channel for
> > the .1) we have 6 channels: left, center, right, rear left, rear right,
> > LFE (see http://lv2plug.in/ns/dev/port-groups#FivePointOneGroup)
> > 
> > What order should these be passed in?  Any existing practices?
> 
> For 5.1 there are several orders in use. Same for AMB, in 
> particular higher order.

Oh well.  I'll just come up with one that seems reasonable and has the
most overlap I guess, and maybe ship a header file with them all
#defined just for convenience's sake (this is all just for convenience,
see below)

> But: either it doesn't matter (e.g. for EQ), and where it does
> matter a 'general' multichannel plugin (i.e. an essentially mono
> one that knows about the multichannel port extension and can
> replicate its internals) probably can't do the job anyway, and
> you need a dedicated plugin.

It doesn't matter in most cases (and all currently existing cases), but
there's easy things to come up with where it would be useful so it's
best to define.  Useful data never hurts.

> What is important is that a dedicated 5.1 plugin should be 
> compatible to a 'general' one that has 'anonymous' or just
> numbered channels, and configured for 6 channels.

Generally the idea with the groups extension is that all grouped ports
are labeled with their 'roles' (this is largely the point).  They're
still compatible with plugins that don't have this data in the LADSPA
sense, you can hook it up manually or with messy heuristics etc.  Note
all this port groups stuff is purely RDF data.  Anything else that needs
to refer to multi-channel would naturally just use these definitions
though, so defining anything that would be useful (like channel order)
is wise, so e.g. things don't end up using a bunch of different
orderings.

Lack of this data just means the host is pretty much screwed when it
comes to doing nice higher level connecting of multi-channel streams.
It's not really feasible to do so, except:

> Also, e.g. an EQ that can be set to six channels should
> work as well *any* 6-ch format. Which means that in that
> case channel names are not a property of the plugin, but
> of the host.

Good point.  I guess nothing really needs to be done here though, the
plugin can just label a bunch of ports as part of a group without a
role.  

> For a dedicated 5.1 or AMB plugin that would be different.
> 
> This suggest that there would some form of trying to match
> a port defined by the host to that provided by the plugin.
> If they are identical, all is OK, but that would not be
> the only case, some other combinations have to work as well.

I generally think of this problem in terms of "plugin telling the host
precisely what it's I/O is".  Hosts can be as clever as they like :)

Ideally (IMO), hosts would look at all the plugins they have to find
converters.  For example, if you have stereo, and need to convert it
into 5.1, check all your plugins for something with a stereo in
corresponding to a 5.1 out.  Hardcoded logic in hosts for this kind of
thing is unfortunate, especially for e.g. ambisonics where it's far from
trivial behaviour.

Thanks,

-dr