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