@Dietz said:

Re: RAM

In a stress test I ran today, I had 50 indivdual VIs playing glitch-free at the same time in stereo, latency set to 1024 samples, CPU @ 80%, with a system comparable to the one you outlined above (12 GB RAM). I used 11.2 GB RAM for this setup, with Nuendo 4 for MIDI output on the same machine.

Taking into account MIR's abilitiy for dynamic processing (only those VI's that really play will use MIR's convolution core and thus tax the CPU), you will most likely run out of RAM before the CPU overloads. 😊

HTH,

If I get an Asus P6T, and want more than 12GB ram what shall I get? Are there any other kits available rather than the Kingston 12GB unECC kit of 3, that costs over $1000? thanks

Hi  Christian and the rest of the Vienna team.

First of all: Congratulations with getting MIR on the market - a big step for Vienna, but a giant leap for mankind -at least composers etc.[;)] 

DG raised an importent question about latency, which sort of got lost in the mail. Running with 1024 is sort of ok when rendering a project, but as DG pointed out: What about the recording phase - when playing, 1024 is simply too much delay for comfort.

Can you operate with a simple reverb setup during recording, allowing you to set latency to say 256 or better still: 128 ?

And then afterwards turn on all the bells and whistles.

Achievable latency is always going to reflect the specifications of your system and the complexity of the project you're running within Mir.

For example, I'm running Mir at 128ms hardware buffer and have no problems whatsoever with what I consider to be decent sized arrangements - say 50 VI instances containing fully scripted matrices, with up to 25-30 of them playing simultaneously.  If I had to do something much more involved I would increase the buffer size if I saw CPU load issues.  That said, I have a very fast quad-core Xeon system which was specified primarily for Mir.

In essence, you're absolutely right, you can always run at a lower buffer setting whilst recording indivdual parts, mapping out ideas and basic arrangements etc. and if you find further down the line that the full arrangement is stressing the system, increase the buffer size when you render the final mix. 

Jules

@hose said:

If I get an Asus P6T, and want more than 12GB ram what shall I get? Are there any other kits available rather than the Kingston 12GB unECC kit of 3, that costs over $1000? thanks

@Trailerman said:

Achievable latency is always going to reflect the specifications of your system and the complexity of the project you're running within Mir.

For example, I'm running Mir at 128ms hardware buffer and have no problems whatsoever with what I consider to be decent sized arrangements - say 50 VI instances containing fully scripted matrices, with up to 25-30 of them playing simultaneously.  If I had to do something much more involved I would increase the buffer size if I saw CPU load issues.  That said, I have a very fast quad-core Xeon system which was specified primarily for Mir.

In essence, you're absolutely right, you can always run at a lower buffer setting whilst recording indivdual parts, mapping out ideas and basic arrangements etc. and if you find further down the line that the full arrangement is stressing the system, increase the buffer size when you render the final mix. 

Jules

@hose said:

If I get an Asus P6T, and want more than 12GB ram what shall I get? Are there any other kits available rather than the Kingston 12GB unECC kit of 3, that costs over $1000? thanks

Hi, It's not the ECC that is the problem (the i7 can just ignore that) but rather the Registered and unRegistered RAM modules. At the moment the 3x4GB DDR3 unRegistered modules aren't really available, although you may see them advertised, they are just hugely expensive first run if you can find them at all.

This will change in the not too distant future but at the moment you do have to go with Registered dimms if you want 3x4GB kits and that means Xeon 5500 series.

Something I will get around to testing shortly is running a 5500 series xeon on a standard desktop i7 motherboard, which does work apparently, but I wonder, because the memory controller is on the chip if that means it will then take the Regsitered dimms, I doubt it but it is worth a try when I get a spare min.

Back to your question though, you will have to wait to use more then 12GB on the desktop i7 systems, probably until the end of the year.

Thanks for the info, and welcome to our little club....! Nice to see you here.[;)]

DG

txh Jules for responding.

I suppose that maybe a dual XEON 5580 can keep up with a full orchestra at 128, so with this system it is not a problem, but what about less powerfull systems like i7 platforms? - here a different approach is needed.  

What I imagine is that you could have all the instruments loaded in MIR without all the positioning/reverb turned on thus preserving power, but with some sort of basic reverb turned on, during the recording process.

The only thing that could be very frustrating is if you have to setup the MIR positions for every project, when rendering, so is it possible to have a template with all your complete orchestra including their positioning, directions etc. but with an on/off switch. On being - "yes compute all the MIR stuff" and off the "bypass the MIR reverb stuff"?

@DG said:

Jules, for me the point is how do you run at a lower buffer whilst programming? Do you switch something off? Can you switch something off? My sessions have around 120 instruments, often with 70 or so playing at the same time, so this is really important to me. Currently I just work without reverb and plugs whilst programming, and then raise the buffer for mixing.

DG

 Hi DG, Sapkiller

Obviously, if a system doesn't really have the grunt to run MIR, then it's going to be a struggle from the get-go.   You also can't (I don't think) turn off the reverb component of MIR altogether and work without it until you're ready to mix, although there are different rooms and some may be heavier or lighter on the CPU than others (again I'd have to check this).  The MIR engine and audio engine seem to be very tightly integrated, so I'm not sure how practical it would be do disable the MIR engine altogether, although I agree that perhaps having a 'dummy' room which reduced the MIR overhead as much as possible would be very useful.  

The number of instruments loaded in MIR doesn't really seem to have a big bearing on CPU overhead - it's how many are playing simultaneously that determines CPU load.   Therefore loading up your template shouldn't be a problem.   If the system could not cope with running the entire arrangement at the buffer size you wanted to work at, you would need to do your MIDI input work within more managable sections, ie. muting any less critical parts whilst you wrote. 

The alternative is to run everything at a higher buffer setting - I ran some tests at 512ms and couldn't get anywhere near the ceiling of the system you see in my sig (50 VI's running simultaneously, all loaded with perf-legato-all, perf-legato-speed or perf-universal matrices - ie. lots of complex scripts running - used about 55% CPU load).   I also found that working at 512ms was perfectly acceptable for writing; heck I've spent years programming beats and doing dance production at 512ms and above and never had a problem.

Taking that further, if I had a slower system, I personally would be happy working at 512ms when writing, muting the odd part and living with ocassional overloads and then increasing the buffer to say 1024 when I was ready to mix.   I guess the answer is to keep an eye on the performance people are seeing from different setups and try and find a performance sweet-spot that fits the budget.

I guess the bottom line is that if you feel you need to work at very low buffer settings (256ms and below), use very large arrangements, and can't bear the thought of muting a few parts whilst you write, then you will need a very powerful system to work within MIR, or you would need to work in VE and then transpose your arrangement into MIR when it's complete. I'd say this is a fairly extreme scenario though.

I hope this helps a little.

Jules

@Sapkiller said:

but what about less powerfull systems like i7 platforms?

such systems can run reasonable arrangements (like the zarathustra in the video) very well - i'd say the higher the demand, the more powerful the tools need to be.

but if i'm not wrong there actually _is_ a bypass button ... christian

@hose said:

If I get an Asus P6T, and want more than 12GB ram what shall I get? Are there any other kits available rather than the Kingston 12GB unECC kit of 3, that costs over $1000? thanks

Most probably I'm going for the following specs;

Asus Z8PE-D12

dual cpu xeon e5520

24GB ram (most probably, since the motherboard has 12 ram slots, I'll buy 2GB chips)

According to some benchmarks I should have more CPU power than an i7 975, and don't have to do any overclocking hopefully. I hope I will have enough power for a large MIR project. Feedback from anyone who has MIR working on a dual xeon e5520, is really appreceated.

Also I have a Tascam FW1804(the rack version). There are Vista 64bit drivers available, therefore I intend to use windows 7 64. Is there anyone who has the same device?? perhaps I can save a few bucks on the audiocard. thanks

i would assume those boards (intel, tyan, supermicro, asus) are all manufactured at the same place in taiwan ... BIOS and a few supporting controllers (firewire, usb, ect) migth be different ...

the 5520: we currently have one for testing, 24 GB RAM, overclocked to 2.9 GHz, not yet finetuned ... very impressive ... seems to be a tick less performant than the 5580 (3.2 GHz)

personally i'm still not sure what the most important part is - CPU speed, memory speed, number of calculation units, level2/level3 cache ... the amount of possible testing scenarios is pretty huge ... we will have to find out.

christian

Thanks Christian. I have both a Tyan and a supermicro motherboard here at work, they are storage servers. and so far, never had any problems. All the other desktop PCs have Asus motherboards. Can't really quarel of any trouble, touch wood. I don't know, but Asus seems like a top brand for me aswell, maybe not so popular for workstations and server perhaps.

@DG said:

Jules, thanks for the reply. it does help to clarify things for me, so it's all good. I have no intention of trying to work at a higher buffer than 256, as even this makes things very uncomfortable. I don't mind muting parts from time to time, but I think that I'm going to need to come up with a different workflow, as there is no way that any of the players I use for live stuff would like to work at a buffer of 512, even when using Direct Monitoring.

DG

Hi DG

Well, it sounds like there is a bypass button, and Christian should certainly know.  I don't recall seeing it, although there are independent dry/wet controls for each instrument, so perhaps that enables the system to bypass MIR.  I'd have to run some tests to establish how much overhead this really saves though.

If you're monitoring directly, I'm not sure I understand why latency should be an issue for live players.  I guess I'm missing part of your workflow, but if all you'd be doing is playing your arrangement back from MIR and recording live audio into your host, with the players monitoring themselves directly from your host or mixer, then latency should not be a factor at all.   Ahhhh (penny drops!) you're probably imagining a system where your host is on the same rig as Mir, in which case if you have to monitor via your host then you have the same master latency, set by your audio hardware.  Personally I never monitor via host software, I use ProTools HD (which has zero latency) on a separate machine for mixing, and Logic Pro on another separate machine for my arrangements, running at low latency, and can record on either system without any significant latency.  I think running big arrangements in Mir, and a host with a load of plugins, and recording live, all on the same system would be pushing things a little.

I will work at 256ms on the Mir machine and I doubt I will have many problems, but then my arrangements are rather less complex than the kind of template you've described.

Jules

Hi Jules, you have described my situation correctly. I have no interest in using more than one machine any more; I've done enough of that.....! As MIR is only outputting one stereo channel (unless one is doing surround), using a separate machine just for recording and mixing would be a waste of effort and hinder my workflow from what I would like it to be.

My pleasure DG.  

I'm afraid I've given up on the one-machine solution, although it's a totally worthy aim.  I just always find that one system to be too heavily taxed to be totally reliable.

Good luck and all the best

Jules

@Trailerman said:

My pleasure DG.  

I'm afraid I've given up on the one-machine solution, although it's a totally worthy aim.  I just always find that one system to be too heavily taxed to be totally reliable.

Hi Jules

I'm not sure why you mean "If you're monitoring directly, I'm not sure I understand why latency should be an issue for live players." ? 

I plan to use a separate machine for MIR, but the latency issue is still in play here too as I see it - when I play on my main keyboard the midi goes though the main DAW then via MOL or similar to the MIR host's instrument, which then introduces an extra 1024 samples delay before sending the audiosignal back via eg. ADAT to the main DAW and finally to the speakers for me to hear. So there is at least 25 ms delay (more likely 35 ms) btw I press a key and I hear the sound playing.

But offcause having a bypass function will help a lot here - running 128 samples buffer instead while recording midi, and then raise the buffer when switching on the MIR functions.