Re: [LAD] Multi-Channel channel order

On Sat, 2009-08-15 at 01:04 +0200, Fons Adriaensen wrote:
> On Fri, Aug 14, 2009 at 05:44:21PM -0400, David Robillard wrote:
> > Jörn Nettingsmeier wrote:
> > > most favoured normalization scheme is sn3d, i.e. plugins will have to
> > > deal with inputs greater than 1.0f.
>
> Not really - for n3d some of the _panning gains_ can be > 1 iff you
> set W = 1. Absolute levels are not the same thing as relative gains.
> For sn3d the panning gains are <= 1.

I'm glad this stuff is actually defined elsewhere. :)

> > > but for political reasons, new plugins should use acn rather than fuma,
> > > so that's what should be defined as a standard first. if there is
> > > sufficient pressure and people are volunteering, another fuma scheme can
> > > always be added.
> >
> > Sounds good to me.
>
> Again I would 100% support that, but it is not current practice.
> Any application that uses this scheme will be the brave one that
> starts a revolution.

As far as LV2 goes, there's basically zero precedent whatsoever, so
brave new world it is.

Whichever is most reasonable if you could start anew and pick a single
standard is the one to choose. If other stuff all bogged down with
legacy is different, whatever. Not everything uses -1..1 float audio
either. Conversion isn't the end of the world. Even if the real world
has a billion different formats, we can at least make this world nicer.
It's the Jack way :)

> > (Fons, what is the situation WRT this stuff with your ambisonics
> > plugins? AFAIK they are the only ones that exist in LAD land)
>
> The plugin set (did you get the latest and greatest ?) uses FuMa
> and also it assumes that positive azimuth is to the right which is
> plain wrong. The only reason for that is that most hosts can't
> create a widget that has negative values to the right and positive
> ones to the left (and LADSPA can't tell them they should do it).
>
> The plugins will remain what they are, but my support for FuMa ends
> there. All new stuff will be n3d or sn3d and use either the 'computer
> graphics' (= ACN) or 'Gerzon' order. If the new stuff is more than a
> plugin it could *maybe* offer FuMA as an option at the external
> interfaces, as e.g. AmbDec does. Internally everything will be n3d.

I was just thinking a direct port to LV2 would be nice, but whatever.
Sounds like a level of abstraction is/will be in there somewhere that
can deal with it anyway.

(You could use the same ontology for lrdf on LADSPA plugins, but the
chances of that actually being used are probably slim. I am not
personally interested in it, anyway, but the ontology is deliberately
simple and 'flat' to make it possible to use in basic things)

> Anyway, if ports are labeled in 'machine readable' way the order
> doesn't matter - a host will be able to sort things out. It does
> matter e.g. in a file format that doesn't have metadata to describe
> the order.

For normal plugins that just use the metadata, it's all based on the
semantic "role" and order is irrelevant.

Dynamic stuff probably needs the order though. Plugin code doesn't want
to have to deal with this crap when the spec can easily make the host
have to pass it in a certain order (when there's a choice, complexity
goes in the host).

> Dave, don't worry about the weird order of the single character
> names shown on the web page about ACN, They are mentioned only
> to show how the order relates to the FuMa one. ACN doesn't use
> these names, it only uses the numbers.

Hrm. I wonder if the names should be changed then... currently they are
wChannel, xChannel, etc.

I'll have to think about how to work both in there without it being a
PITA to query.

> Another outcome of the Graz meetings is that the port groups
> that are currently named H#V# should really be named H#P#.
> The H#V# ones do also exist, but are different. I'll have to
> rename all existing AmbDec presets for the same reason.

OK, thanks

-dr

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