[SOLVED] CPU overload with MIR Pro - MIRx Update!

[Mux]

Hey guys,

I just updated VE PRO and MIR Pro to try out the new MIRx feature.
But since I updated, the CPU is always at 99.2 % and it is impossible to play back without dropouts.
The CPU in the Task Manager looks fine (15-20 %). It's only within Vienna Ensemble.

When I start an empty VE as standalone, everything looks good. When I load a project, the CPU Usage goes up to 83-90% again.
It's usually under 30 or 40 % here.
Any ideas?

Thanks!
-Alex

My System:

WIN 7
XI Machine X2 VSL
32 GB Ram
Intel Hexacore

CUBASE 7.5.0
Vienna Ensemble as plugin (up to date)
Vienna MIR Pro (up to date)

[Dietz]

That's strange. Are you using MIRx Mode already? Or in other words: Are you using multiple Room EQs? Or is it just an "old" project that gives you trouble?

The reason I'm asking this question is that this is the only aspect that has changed massively processing-wise. Everthing else should be more or lesst identical to the previously released version.

 What do MIR Pro's Preferences look like? Did you change the MIR engine's own latency?

Did you change anything in you ASIO-settings?

Is Cubase running at the same time?

[Mux]

I am using a new project from last week. I installed the update and opened it in Cubase as usual. The CPU in Cubase looks as usual (low).
MIRx is deactivated now. CPU at 98%. Right now, there is only one Room Tone activated (default).

VE is running with 12 Threads, Latency at 1024, Cache 4 GB. But that's the same as before. I haven't changed anything.

Cubase and VE are running in Multi-CPU mode. As long as MIRx is activated, even a buffer of 512 samples doesn't work. If I deactivate MIRx I can listen to the music without dropouts at 512, though the CPU is still at 85 - 98% (in VE)

[Dietz]

Martin Saleteg from VSL's software developers team could determine a glitch in the new Room EQ Bank handling. A bug-fixing update is on the way! Thanks for reporting.

Best,

[Mux]

Great! Thanks a lot.
and by the way: brilliant update! Can't wait to use it.

-Alex

[saxmand]

I've experienced the same... Great you reported so fast Alex! MIRx looks amazing. Can't wait for the fix. So thanks to the VSL team!

[Dietz]

In case you missed the news: The bugfixed version is already available form your VSL User Area!

[doubleattack]

It works very fine on Mac; it doesn't so on my Win system. And that's a pity, cause that's my main workstation, dedicated specially to MIR.

Since version 12844 is very stable  a n d  very efficient on the same system, the new MIRx implementation should be not such a dealbreaker.

It's very nice with MIRx to have such good new starting point's - to make a new template is easy, fast and a funny work. So I much appreciate this big effort vsl has made with this update - and it's without any charging again. But please make it running on Win 7 too!

Best

Frank 

[Mux]

No problems here, so far (Win 7). I had one VE crash though, but after a restart everything worked fine. But I will send a log file to the support if it happens again.

thanks for the quick update!
-Alex

[doubleattack]

Good to know. It seems to affect some systems only, what will it makes even not easier to solve the problem, I suppose.

I've tried lot of different things, but I didn't it get to work here, so I have had to switch back to the older version.

[Dietz]

@doubleattack said:

Good to know. It seems to affect some systems only, what will it makes even not easier to solve the problem, I suppose.

I've tried lot of different things, but I didn't it get to work here, so I have had to switch back to the older version.

In case you have a typical example of an VI Frame using more CPU with the latest versions of VE Pro / MIR Pro compared to earlier ones,  it might be helpful to send it to VSL's support, with as many technical details as possible.

Thank in advance!

[doubleattack]

I've already contacted vsl - support and gave them a list about the CPU consumption. Every VE PRO 2 instance took 1,5 % and it stacks up with every new instance. 20 instances = 35%, ways to much obviously.  But the task manager was showing different values[:O]  

Now I wan't install the new update anymore on this system. After the last trying out the switch back was possible with system recovery only. The new features seems to affect general settings, since I've got suddenly the same heavy CPU consumption after installing the older MIR Pro version. After recovery all things went fine again, at this time 81 instances loaded with 4,1% CPU usage, playback at buffer 512 mostly 30% - 40% CPU usage.

A crash dump from my try out was send to support too, maybe it includes some more information.

Kind regards

Frank 

[MWE]

Not 100% sure this is solved.

I understand this could be straightforward: I.e. Yes I changed my project upon dim violas and I see voices push well over 800 in some passages (with a red dashed undocumented feature from which I can guess it is not good) But, I started noticing such after a sudden degradation in performance (99 and something % cpu with 5.3.+) and have never seen this before. In fact I was happily running my projects at 64 bits buffers and currently an increase to 4096 doesn't help at all.

I recall being asked to update VI Pro in order to use dimension violas before attempt MirX in Mir something.

Thanks, Help?,

Martijn

[Timo]

The same is for me. Now I’m doing a string piece with dimensions and solo strings. 32 VIPro Instances only, and voicing jumps to 600+ with red dashed line sometimes starting at 50 voices. The piece is rather slow. I run it on Revodrive3 x2. For an experiment I’ve set buffer size at VEPro and Audio card to very high rate, and changed preload buffer size from 3000??? to default. Get better but still stuttering a lot. The CPU usage although is not very hi, around 30%. Thank you very much for your great job! Timo

[Blogospherianman]

Same here, lots of red bar even at low voice counts. Never acted this bad before,  I'm reverting back. I even get this build up latency now that starts and the more i play the longer the delay gets.  Clicking  when changing cells. Help!

[herb]

 Just clarification, if the red bar inside VI PRO at the voice meter appears, the  hardrive streaming capacity is overextended.

So this is not related to VE PRO per se.

Keep in mind that even with SSD drives the possible voice amount is not that high when multiple audiostreams are forced exatcly at the same time. (burst voices)

This might happen pretty often if you use dimension strings triggering all players simultanioulsy, further performing quantised chords with vel Xfade active, also fast movements of all players in unisono could be very demanding for hardrives.

Best option is to set the preload buffersize of VI PRO to a higher value (don't mess this up with the buffer size of the audio hardare),

and also distributing the sample content to different hardrives migt help.

best

Herb

[Blogospherianman]

Is it ok for all Dimension String Sec. to be in 1 dimension folder, or should they be split differently?

[herb]

 If you have just one harddrive ofcourse it's OK to place them in one folder. If you want to distribute on multiple drives you have to split the content to different folders. For example Violins on one drive, violas and cellos on a second one.

best

Herb

[Timo]

I’ve found why I had 600 voices just for the Dim Strings + Solo.

   At first I used mostly leg. and sus. patches and all of them were slot Xfade with non vib, even though I didn’t use it, they as I understood, sounded virtually. I’ve delete them and voicing dropped down to 300.

Than I turned vel Xfade off and they went down to 70.  I will finish this piece with vel Xfade on, it works fine for me, but glad that found the problem.

  May be I didn’t read manuals carefully, but is it mentioning somewhere that slot Xfade and Vel Xfade multiplying  voices in so many times?

[MS]

Being able to fade between the different layers in realtime naturally means that all layers have to be playing. With x-fade disabled, the velocity layer can be chosen beforehand, depending on the played velocity.