< Back to IRCAM Forum

Speaker orientation?

Spat
#1

Greetings!

From what I can determine, spat~ is designed such that all speakers are pointed to a theoretical sweet spot in the center of the space. I often find myself in situations in which the speakers cannot necessarily be aligned in such a way – am I correct in assuming that there is no way to compensate for this?

Given the thoroughness with which most things are covered in spat~, I’m sure some thought has gone into whatever decision was made about this, and I’d also be interested in hearing the reasoning behind it (mostly so I can tell my students!)

Thanks,

\M

#2

Hi Matty,

From what I can determine, spat~ is designed such that all speakers are pointed to a theoretical sweet spot in the center of the space.

Indeed.

I often find myself in situations in which the speakers cannot necessarily be aligned in such a way – am I correct in assuming that there is no way to compensate for this?

At least there is no easy way.
Assuming that you know the (frequency-dependent) directivity function of the loudspeakers, you could somehow compensate for their orientation. But there is no built-in function to do so.

Given the thoroughness with which most things are covered in spat~, I’m sure some thought has gone into whatever decision was made about this, and I’d also be interested in hearing the reasoning behind it (mostly so I can tell my students!)

Not so much reasoning.
Panning algorithms are built on the assumptions that the loudspeakers are :

  • with a flat-ish frequency response,
  • equidistant to the sweet spot (or delivering the same power, and in-sync, w.r.t. the sweet spot),
  • pointing towards the sweet spot,
  • in a dry-ish room.

If that is not the case, then someone (the FOH engineer ?) should “calibrate” the system so that it behaves “as if”.
The equidistance hypothesis is easy to circumvent; you can e.g. use spat5.align~.
The orientation hypothesis is bit more complex/annoying.
The interaction with the reproduction room is yet another story…

Best,
T.

#3

Hi Thibaut,
Thanks – Now that I spend 30 seconds thinking about it, of course. I’ve also done a lot of work with MIAP, which is of course a completely different conceptual model, so I hadn’t really thought it through.

Now that you’re mentioning spat5.align~, I noticed today while putting something together for my students that it doesn’t take the @embed attribute, so one always has to pass the speaker positions to it at load. Not the end of the world, but it seemed inconsistent…

Best,

\M

#4

The @embed attribute is only available for GUI objects.

For non-UI objects, I have the impression that their state has better be declared with loadmess or @initwith i.e. be declared explicitly and upon initialization of the patcher.
But feel free to let me know if you disagree.

Best,
T.

#5

I can see how you might want to limit the @embed option to contexts where it was visually easy to see exactly what information had been stored, either by looking at a UI object or seeing the initialization information.
That being the case, perhaps it would be a good idea to have the documentation reflect that – in all the information regarding state saving (such as spat5.tuto-osc-2 and -3), there’s no distinction made between UI vs. non-UI objects. So when spat5.align~ threw an error, it’s easy to assume that it’s a bug.

Looking at the refpages, I can see that @embed isn’t listed there, but it’s a bit more digging than one might want to do, so it might just be helpful to have that information a bit more forward-facing…

Thanks,

\M

#6

Thanks for your suggestions !
I’ll update the documentation accordingly.

Best,
T.