@Another User said:

 But what I don't understand:  with VE Pro I only have so many different VIs per instance... how will this be reflected in MIR pro?

... sorry for being dense, but I don't understand the question ...? 😕

@DG said:

I would, however, suggest that you make sure that this information is prominently displayed, to make sure that PT users know why MIR won't work properly in their set-up, unless they have nothing else loaded, or are prepared to shift audio tracks around to accommodate the latency.

I second this, otherwise ppl would be led to believe that the MIR instantiation would create a latency that Pro Tools was able to deal with.

What latency do you commonly deal with when using MIR Pro so far, and at what buffer size, of course?

@DG said:

I would, however, suggest that you make sure that this information is prominently displayed, to make sure that PT users know why MIR won't work properly in their set-up, unless they have nothing else loaded, or are prepared to shift audio tracks around to accommodate the latency.

I second this, otherwise ppl would be led to believe that the MIR instantiation would create a latency that Pro Tools was able to deal with.

What latency do you commonly deal with when using MIR Pro so far, and at what buffer size, of course?

I don't have MIR Pro (obviously) but with standalone MIR the buffer and latency is totally dependent on how many instruments. MIR has a buffer multiplier, so that even when your soundcard can't do large buffers, MIR is able to work.

Maybe if you state how many instruments you are intending to run, Dietz will be able to give you an idea.

FWIW I can't run my template at any buffer with the current version of MIR. [:(]

DG

@DG said:

[...] Maybe if you state how many instruments you are intending to run, Dietz will be able to give you an idea. [...]

With my 3 years old development machine (basically an INTEL Core i7-965 XE 3.20GHz Quad-Core with 12 GB RAM and a RME Hammerfall DSP for audio), I usually use MIR with 1024 samples latency and a buffer multiplier of 1 for 30 to 50 instruments. For more instruments I need higher buffer multipliers.

512 samples latency would work, too, in most cases, while with 256 (and a multiplier of 1) things get messy with more than a dozen of instruments. 1024 is smooth and responsive for mixing. - This makes for a total latency of 2048 samples.

HTH,

Another example: These are results of a more powerful system, posted on the beta-list by user "Wolfgang" about two years ago:

@Another User said:

Primary System: I really have not been able to stress it

128 latency: roughly 50-55 instruments @ 65-70% cpu

512 latency: 80 @ roughly 65-70%

1024: over 100 instruments @ 75%

Like Dietz, I used Perf Legato patches for each instrument. Same line with adjusted ranges. Buffer @ 1. Bringing buffer up allowed me even more cpu room to work with.

Note: This was a stress-test , with all instruments playing at the same time! In real life, one can achieve better numbers than that due to the fact that MIR is able to switch off convolution threads that aren't used at the moment.

That eases my mind. [:)] 2048 buffer is usualy enough in my sessions in protools, 4096 when the going gets tough. Worst case one can alway bump protools up to 8192 samples, but of course it would be nice to avoid this for the sake of playability.

One more question, since you are so wonderfully forthcoming about the development:

Previously you have exclusively recommended memory controllers in the X58 league, but have you done any tests or have any opinions regarding any of the dual memory interface options like the i7-based H67, P67 or Z68s? Will they struggle coping with the engine, and if so, do you think overclocking would make them able to handle the high throughput? Obviously the X79/LGA2011 platform will be a fantastic rig for running things like MIR if the rumored specs have any truth to them, but the Sandy Bridge-based platforms does offer quite a bit more value for money than enthusiast ones like the X58 and, very likely, X79s do.

Any thoughts much appreciated. [H]

Whew! I have to admit that I'm not the local hardware guru (I'm just an audio guy ;-) ...) To be honest we are developing on the same machines since quite some time now, and new hardware-tests won't take place before the software itself isn't feature-locked. But I will ask around, maybe our IT-guys can offer an educated opinion.

Kind regards,

BTW ... which flavour of ProTools offers more than 4096 samples of latency compensation?

@Dietz said:

BTW ... which flavour of ProTools offers more than 4096 samples of latency compensation?

All flavours. It depends on the sample rate you're working at. However the actual amount of ADC allowed is still the same in ms, so it solves nothing.

DG

Ok, thanks, that's what I thought too, but Vagn Luv's message seems to imply that there are other possibilities I'm not aware of.

I hope MIR Pro development is taking into account Mac OS Lion's imminent release, as hopefully it does for all VSL software.

@Another User said:

 But what I don't understand:  with VE Pro I only have so many different VIs per instance... how will this be reflected in MIR pro?

... sorry for being dense, but I don't understand the question ...? 😕

...sorry, I kind of read over this... sorry what I meant was the following:

 when I open one instance of VEPro as a logic-plugin, I can only use 16 MIDI channels (or VIs) per instance. As this is a limitation caused by logic rather than VSL software I would be curious, how MIR PRO will deal with this limitation (as my current template includes around 60 instruments). Will I have to use multiple instances of MIR (as in VEpro) or will there be a possibility of extending channels like a multi-multi instrument.... 

and then, will I be able as in VEPro to route the individual instrument output to a separate bus (I am not sure if I would want to do this, as in a way this seems against the primary MIR concept to me (another external mixing point)... but anyway, it would be interesting, if it would work)? 

Greetings,

Patrik

There will be a built-in solution especially for those poor souls who have to use Logic. [8-|] A workaround, of course, but it will work.

@Dietz said:

those poor souls who have to use Logic.

I don't understand it either. Apple is always years ahead in design and architecture, how are they so far back with this AU limitation, especially when they do take themselves seriously in this industry (building programs like Logic, Soundtrack, and Final Cut PROs).

Logic is so behind in some domaines, because they are years ahead in others (64 bit). Hopefully the new Logic X (slated for this summer) will give us lots of surprises!

@musos said:

This is really not an appropriate or polite statement from someone who works for VSL.

I'm pretty sure Dietz wasn't being completely serious with his comment. I think it's possible to find a bit of banter there.