Speaker positions file syntax.

[e deleflie]

> On Fri, Apr 24, 2009 at 2:37 PM, e deleflie <edel...@gmail.com> wrote:
>>
>>> And I think you are again trying to solve to many problems with a new
>>> standard (IMHO). Few people will care about what MUST be supported,
>>> just because there is some new standard. You don't want to do
>>> Universal Ambisonics certification, do you?
>>
>> yes.
>>
>> well, that kind of thing. If someone labels something as Universal
>> Ambisonic but doesn't implement all defined speaker array decodes then
>> everyone loses...
>
> The biggest problem is the implementation. What we need is a standard
> decoder library, preferably under BSD, LGPL or similar license.

Perhaps the standard will make it easier for software implementations.
I'm wondering if I should put out a carrot ... first full
implementation of Universal Ambisonic Decode gets a 1 year free
pro-account on the new Ambisonia site.

>What also could improve the situation is a file format for storing decoding
> equations / speaker presets. Configure it once - use it with any
> Ambisonics decoder or automatically generate a LADSPA-plugin,
> VST-plugin or a Jack application.

Given that Universal Ambisonic defines default speaker decodes,
perhaps they can just be numbered ....Universal Ambisonic Array 1
(which would be stereo).

or perhaps not ... since the standard encourages decoders to implement
arbitrary speaker positions (on top of the default arrays).

Fons uses an OSC type syntax for his speaker positions on AmbDec ...
but I'm not sure what the advantage of this is. Is there a case for
sending OSC messages that define speaker positions. I dont know.

Here's a thought .... the syntax used for the producers recommended
stereo decode should 'tie in' to that syntax a bit.... I say a bit,
because its kinda different, a bit.

Etienne

[Aaron Heller]

On Fri, Apr 24, 2009 at 4:22 PM, e deleflie <edel...@gmail.com> wrote:
> Here's a thought .... the syntax used for the producers recommended
> stereo decode should 'tie in' to that syntax a bit.... I say a bit,
> because its kinda different, a bit.

I know that some of you will gag at this suggestion, but I happen to
like comma separated values (CSV) files for stuff like this. You can
make and edit them in Excel, or Open Office or Google Docs spread
sheets, and there are lots of people who are comfortable with those
who would cringe at using other editors. I have some MPL'ed C++ code
that parses CSV files.

Perhaps something like:

DESC, description

SPKR, name, srf, v1, v2, v3

where srf is spatial reference frame, one of
srm for spherical radians and meters
sdm for spherical degrees and meters
cm cartesian meters

and v1, v2, v3 are the coordinates in the srf

then the code that designs a decoder could add lines like

BANDS, n_bands, xover1, xover_i, ...
GAINS, band, g0, g1, ....

COEFS, name, band, gK0, gK1, .....

any line that does not start with a reserved word is ignored as a comment.

[Oliver Thuns]

We need some XML with DTD, namespaces and all that stuff... ;-)

I don't want to discuss the format now, I'm more interested in the
content. Everything that is human readable is fine for the discussion,
CSV, ambdec osc style, YAML, JSON, Apache config style, etc...

But let's postpone the discussion and let etienne finish the Universal
Ambisonic ducument first.

[e deleflie]

I dont gag over CSV :)

but, yeah, as Oliver says, lets postpone this bit.

Etienne