Spherical to Cartesian Panning Conversion

[ScuzzyEye]

So I'm using Fiedler Audio's Dolby Atmos Composer to do object-based panning. I really do feel that this plug-in with Reaper is one of the best ways to produce Atmos content at this point in time. I very much prefer it over Pro Tools, Logic or Studio One, if just for the routing options that Reaper has. (I've even come to embrace the lack of post-fader inserts, because having the Beams as sends actually works better for me now.)

There's only one thing missing from this setup. Reaper doesn't know about the panning being performed by Beam. If you enable the pass-through audio, you only get out what went in (perhaps with volume adjustment). So you might be panning a mono object, and you'll hear that immersively mixed for playback, but it's still mono to the Reaper track. Now, I also have Fielder's Spacelab Interstellar. While it's an excellent reverb, I also have about a dozen other immersive reverbs, along with tricks for making stereo reverbs into multi-channel in/out. So it would be really nice to pan a channel in Dolby Atmos Beam, and then send a similarly panned signal to one of those reverbs.

Easy you say, Reaper has ReaSurroundPan, it does just that! And I'll reply, we're on the same page there. But one of the best things about object-based audio is that you move can objects around in the mix. So you'll want to automate the panning of some objects. Or at a bare minimum, be able to adjust the panning during the mixing process, and not have to do the work twice. Once in Beam and again in the Rea Pan. Now I know you're thinking, simply link Beam's controls to Rea Pan, because that's another amazing thing about Reaper you can link two plug-ins together so you only have to adjust one. I'm there with you again. But... Dolby Atmos Beam uses spherical coordinates (azimuth, elevation, distance), but ReaSurroundPan uses Cartesian (X, Y, Z).

Here's a strange fact about me. I've written code for spherical (or polar) to Cartesian conversion so many times in my life. I honestly don't know why it keeps coming up. So that's the easy part. I've never written a JSFX, or anything in EEL. At least until today. So now I have a really simple (MIDI) JSFX that can be linked to Dolby Atmos Beam, and then ReaSurroundPan can be linked to it. You move a knob in Beam, and Rea Pan follows.

Might as well show you what I have so far. (Forgive the bleached colors, my display is HDR and I forgot to tell the capture program that fact.)

OK, got that? I absolutely will post the code for the effect here, but want to clean things up a bit, and maybe make it more useful. First, would it be useful?

Right now, you have to set some of the offset and scale values for the linking. I'm not 100% sure I can make it not require any adjustments, but I can look into it. I imagine most people would save the FX Chain, and that preserves those settings. The values used are basically -50%, +/-100%, and +200%. Not difficult to dial in, and it might be useful to know what you're doing there anyway, so you can do things like make the panning to the reverb send the inverse of the Atmos object.

Right now it's for one channel. I'm definitely planning to add a second set of controls. It is a "MIDI" effect, so you don't have to worry about pinning the correct audio channels to pass audio through it right. So I could even keep it 1 channel, and you could simply insert one for each channel you want to link the panning controls for. Something I noticed, both the Atmos Beam, and ReaSurroundPan allow automation of 16 channels (coincidence?). So maybe make it 16 channels? I think showing 96 sliders would be an absolute mess though. So I'd have to figure out how to make that selective (I'll save that for my third day of writing JSFXs).

[plush2]

This is a great idea. Being able to embed the panner in the track itself is another plus to using Reasurroundpan. I have also done my fair share of spherical/cartesian conversions so if you want some help or need some testing I'd be happy to assist.

[jm duchenne]

Perhaps that the CoordinateConverter plugin from the IEM suite could be also useful ?
https://plugins.iem.at/docs/pluginde...inateconverter

[ScuzzyEye]

Originally Posted by plush2

This is a great idea. Being able to embed the panner in the track itself is another plus to using Reasurroundpan. I have also done my fair share of spherical/cartesian conversions so if you want some help or need some testing I'd be happy to assist.

In the case of embedding ReaSurroundPan, would you want to use that as the panner and have Atmos Beam follow?

Right now my converter is basically treating the XYZ as "read only". One optimization I was going to make, especially if I add 16 channels, is only doing the sin/cos calculations when a slider that affects them is moved. (E.g. distance doesn't change the angle, only the scaler.) If I'm actually paying attention to which slider is moved, I could possibly make XYZ also be an input, and when they are moved it sets the rθφ. The math for that direction is worse, and there are some inputs that have more than one solution (or infinite solutions), so there will be a lot more conditionals involved.

I already have the IEM suite installed, I'll see how their convert works. If there's already an existing solution that works well in both direction, this might be moot.

[plush2]

Originally Posted by ScuzzyEye

In the case of embedding ReaSurroundPan, would you want to use that as the panner and have Atmos Beam follow?

That was my thinking, yes. I recall that your main use case was for sends to mirror the main output panning of the track.

[ScuzzyEye]

Originally Posted by plush2

That was my thinking, yes. I recall that your main use case was for sends to mirror the main output panning of the track.

Yeah, the Atmos Beam plugin takes a number channels in, and passes them through. But when they're "beamed" via inter-plugin communication to the Atmos Composer, the panning metadata is comes along with it.

So I was already doing my panning in Atmos Beam, but wanted to actually pan those channels of passed-through audio, and mix them into discrete speaker locations. That way I could send them to multi-channel reverbs, and use the reverb output as an Atmos bed.

It was just my order of thinking, I already had the panning happening in the Atmos Beam, and I wanted something match that. But there's no real reason that something else could do the panning, and Beam follow instead of lead. (Other than the math being more messy.)

I'll start testing some code to see how easy it is to make the Spherical controls follow the Cartesian when they are moved, while still having the Cartesian follow the Spherical. And work from there.

[ScuzzyEye]

The IEM Coordinate Converter can indeed work in both directions. I just threw this together to see if it'd be usable with an embedded ReaSurroundPan driving Fiedler Audio's Dolby Atmos Composer Beam. You'll need all three of those plug-ins available to make this work.

I think I definitely prefer the spherical coordinates driving the Cartesian. The IEM converter has the exact problem I was imagining, the solutions converting back to spherical are tough to guess what motion is intended. Straight lines or arcs are not intuitive, and when you cross the center it's really messy.

Try it out, you'll see what I mean.

[plush2]

Originally Posted by ScuzzyEye

The IEM Coordinate Converter can indeed work in both directions. I just threw this together to see if it'd be usable with an embedded ReaSurroundPan driving Fiedler Audio's Dolby Atmos Composer Beam. You'll need all three of those plug-ins available to make this work.

I think I definitely prefer the spherical coordinates driving the Cartesian. The IEM converter has the exact problem I was imagining, the solutions converting back to spherical are tough to guess what motion is intended. Straight lines or arcs are not intuitive, and when you cross the center it's really messy.

Try it out, you'll see what I mean.

To be honest it wasn't as bad as I was expecting. To me the larger cartesian problem is always that the idea of functionally panning to that position is notional at best and usually just equates to summing or omni type representation. I guess the use case would determine if the cartesian to spherical linkage was useful. If there wasn't a need for smooth 'through the middle' panning and there also was no need for a 1 to 1 correlation between what Fiedler produced and what that Reasurroundpan would produce if it were passing audio then I would say you have a workable solution.

*edit - To bolster my assertion that panning through the center is notional I can point to the shaped direction of the Atmos panner that by design keeps the audio paths away from that location.