Re: [LAD] Multi-Channel channel order

On Sat, 2009-08-15 at 00:38 +0200, Jörn Nettingsmeier wrote:
> David Robillard wrote:
> > On Fri, 2009-08-14 at 22:54 +0200, Jörn Nettingsmeier wrote:
>
> >> most favoured normalization scheme is sn3d, i.e. plugins will have to
> >> deal with inputs greater than 1.0f.
> >
> > Hm. I never considered normalization... the reasoning and details
> > behind this seem to be pretty deep. I will maybe just say SN3D is the
> > normalization that should be used, and that's that?
>
> fine. it's just that plugins *will* have to deal with signals greater
> than 1.0 in some channels, because that's how BOB wants them to be.
>
> > This is similar to what we've done with LADSPA and LV2 and Jack anyway.
> > Audio is -1.0 .. 1.0 float, not clipped, period. Picking the/a best and
>
> extra emphasis on "not clipped", no mention of -1.0 .. 1.0 :-D

I just meant this is what normal audio is in LADSPA/etc, i.e.
historically we've just picked one and said that's it, and it's worked
fine, so there's little reason to try and accomodate a bunch of
different ways to encode ambisonic streams and make everyone have to
deal with that nuisance.

> >> of course, most applications up to now use the furse-malham standard of
> >> w xyz rstuv klmopq, each being normalized to 0..1, with the exception of
> >> W, which is additionally divided by sqrt(2).
> >
> > That the letters aren't in any really sensible order in ACN does seem
> > pretty weird.
>
> the weird thing is the order of the WXYZ... scheme. when you look at the
> spherical harmonics components, WXYZ... is a pile of historic junk that
> is totally unintuitive. consider for instance the components which are
> invariant under z axis rotation:
> W: first (and only) of the 0th order components
> Z: last of the 1st order components
> R: first of the 2nd order components.
>
> so it's time to do away with backward compatibility in this case and
> create a better world for our grandchildren, even if our generation has
> to suffer in this world.

Should have changed the letters too in the process? :)

I agree historic junk should be cast away in general, and /definitely/
in this case. Shiny new specs = opportunity to fix past mistakes...

> >> 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.
> >
> > (Fons, what is the situation WRT this stuff with your ambisonics
> > plugins? AFAIK they are the only ones that exist in LAD land)
>
> there is also the CMT toolset by richard furse.
> both furse and malham have expressed no regrets at doing away with FuMa
> at this year's ambisonics symposium...

If ever there was a plugin collection that needs some love, that's the
one; the nemesis of valgrind loving LADers everywhere :)

> i know fons hates fuma and has publicly stated he wants to get rid of
> it, even though the current AMB set still uses it for historical
> reasons. there will probably be adaptor plugins for a transitional
> period - i recently used a quick hack to interface FuMa plugins with the
> graz cube, who can only deal with ACN and their own in-house scheme
> (which is being phased out in favour of ACN).

Hm. Unfortunate. No straight port then :/

Though if there's two (open) plugin collections that do ambisonics, and
the authors of both hate fuma, the LADSPA stuff can just move to ACN
along with ports anyway.

What is the result if you connect a fuma stream to a ACN stream, getting
the channels matched correctly but just not the normalisation? Is it
just clipping, or is the interpretation completely different?

-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:10 2009