Originally Posted by: 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.
Thanks for your reply!
Originally Posted by: Dietz 
- More latency means less CPUload 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.
That’s MIR’s buffer multiplier, correct? If my buffer is set low-ish to start - say, 64 but ASIOGuard bumping it up as it does - can I set MIR 3D to a specific size or is it a multiple of the DAW buffer? I ask because I wonder if MIR would shift its value when I put a track in record.
EDIT: I see the answer in your picture.
Originally Posted by: Dietz 
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.
Cubase can always be on a lower size on the record track, so I shouldn’t have to change that. But by “deactivate” you mean “remove”, not just bypassing, yes? And so when I’m done playing on that track, I need to re-instantiate it on that channel and recall a preset? Hmm. Even doing that with track presets on a macro (“recall selected track’s preset with ‘MIR’ in the name” or something) seems pretty cumbersome when I’m in a hurry. I will have to think about that.
Originally Posted by: Dietz 
- 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.
But if Dynamic Processing is on, then at least it wouldn’t be using the cycles for convolution etc., correct? Just sort of holding the door open, with the latency as well?
Originally Posted by: Dietz 
- Make sure that "Dynamic Processing" ist 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.
I will give it a go when the new computer shows up.
Originally Posted by: Dietz 
- 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!