< Back to IRCAM Forum

3d speaker configurations with hoa2d

Hi all,

I’d like to test out a mixed order system where I use hoa2d along the horizontal plane of a 3d dome to achieve more precise source localization, as I have a much denser speaker layout there. When I initialize [spat5.hoa.decoder~] i get a warning saying that:

the loudspeaker setup not is planar, which is inappropriate for 2D HOA decoding. Use at your own risk.

Ultimately, i’d like to keep things as simple as possible (i.e. avoid sending separate speaker configs and reassembling the output signal), so my plan was just to “zero-out” all of the non-xy plane channels of the resulting mc.signal and send it to the outputs. Is there any reason why this would not be a good idea (aside from being a bit computationally wasteful)? Thanks!

EDIT: i’m not in the lab now to test, but the output looks reasonable at least…

Hi Eric,

I might be wrong, but I believe the two approaches wont yield similar results.
I know this seems a bit cumbersome, but you’d have to use a separate 2D HOA decoder, to which you send the coordinates of only the horizontal speakers.

Best,
T.

Thanks Thibaut!

I think it should’t be too complicated - I can set something up with odot to filter out the speakers that are not on the horizon during the assignment process.

But that brings me to a follow up question: is it ok if my /speaker/n/aed messages don’t start at n = 1? i.e. for hoa2d I would only use speakers 9 - 24 in the dome, so can I keep the same names when I assign them in spat5.hoa.decoder~?
cheers,
-eric

The speaker indices need to start at n=1.
i.e. you’d need to replace /speaker/[9-24] with /speaker[1-16]
This is probably an easy job for odot.
Alternatively you could use spat5.osc.replace.

Cheers,
T.

1 Like

Thanks!

This is one of those tasks where it would just faster to manually edit the file, but I gonna do it with odot b/c it’s more fun (and i suppose it’ll help me to actually learn how to use o.expr.codebox)… ha