SurroundByUs.com

This is the discussion thread for Surround Panning Tools for producers and musicians: viewtopic.php?f=23&t=227

Thanks so much for taking this thread forward. I'm really excited about trying out these tools in Bidule on the Open Labs DBeat.

how to use?

thannks

I just updated the Wiki with the instructions.

That's outstanding. On my side, I've been able to figure out how to route the touch screen virtual controls in "Riff", the Open Labs VSTi host, to the MIDI input of the SPEC group in Bidule. Essentially, it means having the Riff app instantiated as a ReWire slave and *instead* of using the MIDI output of the ReWire instance - open up an Open Labs MIDI input object and route the MIDI from there. It's a little complicated to read, but I'll post a screen shot and probably will do a demo video of the setup to post on my own blog. That way I can set up any number of touch screen "XY" controls and use that to control the surround position of any number of outputs. Pretty. Slick.

And of course - you *know* I'm going to complicate things, right?



I'm starting to get ambitions for stereo routing into the surround field, by instantiating two SPEC group objects and routing the R & L output from the synth/host app into each - with the angles offset in each SPEC instance to keep the channels "separate" from each other in the field, but still tracking the same relative position. What do you think about a group that has a stereo input with a single angle offset control?

RE: the stereo group. You could do that with ZPan. As "shipped" ZPan has linkage between the left and right angles (both front and rear, in pairs) so that they move towards or away from each other when you move the left pan angle. That is to widen or narrow the sound field.

By changing the math they could move together, but at some fixed angle apart.

Re using SPEC to change stereo to surround, I've been expecting us to go there. One challenge (for live performance) is the latency in Plogue's FFT-->iFFT bidules, and the DSP load. When we use SPEC for stereo to surround conversion everything is optimized for highest quality and lowest DSP load (so we can live monitor, and offlinge processing happens as fast as possible) but that is at the expense of latency.

For instance we always run Plogue @ 512 buffer size.

For single instrument sounds I would think that smaller buffer sizes and smaller FFT and overlaps (prefrences-->DSP settings) might be fine but I don't know if the latency would be acceptable for live. You'll have to tell me.

I figured as much on issues regarding the latency/load balance. I suppose I'll need to try a few things with the Open Labs DBeat under load, to see how things bear out.

And of course - to keep context, as far as keeping things "close to the metal" on latency, one of the primary processors I'll be running are two instances of Guitar Rig - one for bass and one for the guitar side of the Mobius Megatar. That's not to say that they'll both be running at the same time - all the time - but they will be resident and available on each set. Depending on how the DBeat holds up, I may set up some triggers in the Riff app to turn processing ON and OFF depending on which one I'm using for a particular song.

Secondly, there will be a synth like XPhraze running in "Xmode" triggering patterns and phrases, with Ableton Live and FLStudio's Deckadance thrown into the mix running loops and tracks. Again, they all may not be running simultaneously, but it's not out of the question, either.

These of course don't need to have realtime latency like Guitar Rig, but of course it does go to overall load. For the most part I plan to use Live for driving loops of material developed on my main DAW in Cubase/Nuendo, so the possibility of adding load by doing heavy realtime DSP processing in Live is minimal (maybe some accents for beginnings/endings of sets).

So for now I think I need to do a bit of work on my side to see what's plausible within the processing power of the DBeat. If it comes down to driver strain on the embedded PreSonus FireBox, I *can* take my RME Fireface 400 from my desktop DAW and connect it to the DBeat to see how that fares. The RME drivers are crazy efficient and might give me the freedom to do what I want - as long as it fits within the overall CPU capabilities of the machine.



I'll give it a try this weekend and see how things go. There are several places that the DBeat displays CPU load (aside from what Bidule displays), but I'm not sure how much any of those metrics can be trusted. That, too will be part of the discovery process.

FYI, I've figured out how to control the panner from an iPhone/iPad/iTouch, using OSC.

If there is interest I can post and updated group and instructions.