MIR 3D workflow, latency, DSP handling

[dragsquares]

Hi folks - As a composer I mix as as I go and I also perform a lot of things with modeled instruments and VSL libraries, so latency is always a concern. I am preparing to do a rather large upgrade to the rig, and considering adding MIR 3D when I do. (I’m currently using some other placement/ER software along with various reverbs for cinematic tail.) My impression is that MIR 3D is not specifically designed for this use case - which is not a weakness in the app, just not what it’s for. If this isn’t the case - that it functions at very low latency sufficient for real-time performance - I would love to hear about it. Anyone using a Mac Studio Ultra on large templates not 25 tracks, but hundreds - and using MIR 3D in Cubase? And how much latency are you experiencing on new VI tracks at Orchestra-playback track counts? Any special bussing setups that optimize DSP usage? My thought was that I would for example arrange string sections from various libraries such that each one might get a little pre-processing and then they would all feed a “First Violins” bus into MIR. Feasible? Inefficient? Would that play hell on ASIOGuard? And beyond that - if I set my template up with MIR and then bypass it per channel, will its additional buffer latency go away? Is it still using DSP? (So I could bypass it for a performance that requires minimal latency and then re-enable it.)be, but mir is its own weird animal. wondering how cubase handles this. also wondering if mir will allocate dsp of a single instance of its use per channel in the way that other plugins do - that its dsp stays on the same core the channel is using - or if because of its buffering scheme it uses another set of cores that all instances send to. finally, wondering if an apple silicon native version of this is imminent.

[Dietz]

Hi Richard,

all very valid questions, but the answers would depend very specifically on your setup and the individual workflow. Let me try to show you a few approaches that might help you to optimize MIR and its environment yourself.

- More latency means less CPU load from MIR - it's a simple as that. 😊 This is true both for the audio system itself as well as MIR 3D's own buffer size. I suggest to assign at least 1024 samples of buffer to MIR, maybe even 2048. My suggestion is to simply de-activate the channel's individual plug-in for real-time recording while switching the DAW to its low-latency mode at the same time.

- Latency-wise, bypassing is not the same as de-activating a MIR instance! A bypassed instance is still "available" from your DAW's point-of-view and will still trigger the latency compensation of your DAW.

- Make sure that "Dynamic Processing" is turned on in MIR's Preferences. That way only instances that actually process audio will tax your CPU:

- Creating "virtual ensembles" in the form of sub-mixes of (ideally very similar) instruments to use a single instance of MIR 3D instead of many is not the "official" way to use it, but it is still a very viable one.

- Your host and/your OS are responsible for core-handling and multithreading. MIR has no direct influence on these areas, AFAIK (but I could be wrong - I'm a sound engineer, not a software developer). Same is true for the status of native Apple Silicon code, sorry. 8-)

HTH,

[dragsquares]

@Another User said:

- Your host and/your OS are responsible for core-handling and multithreading. MIR has no direct influence on these areas, AFAIK (but I could be wrong - I'm a sound engineer, not a software developer). Same is true for the status of native Apple Silicon code, sorry. 8-) HTH,

Very true, and very helpful. It’s my understanding that the reason why one has to be careful with bussing is that everything in a channel is going to be processed by the same core, so if there’s a lot of elaborate bussing it’s much harder to be efficient, and the system can get inordinately bogged down. But I’m a composer, not a software engineer. 😁 Your comments are greatly appreciated!

[Dietz]

You're welcome! 😊

@dragsquares said:

[...] But by “deactivate” you mean “remove”, not just bypassing, yes? [...]

No, this means that all settings remain unaltered, but no processing whatsoever takes place. ... think of it as some kind of local memory for a plug-in that's not instantiated at the moment.

-> see this Cubase online help section

HTH,

[Dietz]

Another notable recent addition to this older thread is the introduction of Vienna Power House, which not only reduces the load on the CPU, but also allows significantly lower latencies for MIR's convolution threads.

[ChristaFordham]

@Dietz said:

You're welcome! 😊

@dragsquares said:

[...] But by “deactivate” you mean “remove”, not just bypassing, yes? [...]

No, this means that all settings remain unaltered, but no processing whatsoever takes place. ... think of it as some kind of local memory for a plug-in that's not instantiated at the moment.

-> see this Cubase online help section

HTH,

Thank you for shedding light on such an important topic.

[Dietz]

You're welcome! 😊

*****

Sidenote, just to avoid confusion for the occasional reader: This thread started over a year ago. MIR 3D is happily running on Apple Silicon these days!