Cameron,
What I’ve done is to abstract the 3D positioning calls for Sampled Sounds and Events such that the main app doesn’t care what they are under the covers, it can just position them.
In addition, in our application, we have a non-standard speaker layout (for example, the side surround speakers are located at specific angles to the listener (right is right and forward; left is left and aft). The SetSpeakerPosition calls work very nicely to locate these speakers at their actual positions such that 3D positioning works smoothly around the listener when positioning 3D sampled sounds.
It was our intention that we’d simply use the same set3DPosition call to place event sounds in the same audio space (i.e., adhering to the unique setSpeakerPosition layout). As the overload is virtual, we can position a sound in 3D space and let the overload determine if it’s calling the sound/channel 3D position method or the Event/ChannelGroup 3D position method.
That’s when we found what appeared to be the Event 3D position spatializer not being aware of the audio layout set by SetSpeakerPosition.
Hopefully, there’s a better way of going about this, as your comment about not poking around in the Core API for Studio-based sounds makes sense.
Regards,
Bill