14 Aug
2009
14 Aug
'09
3:52 p.m.
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:
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)
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. 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