Working on a film and I cannot export a review copy of a reel at a time without ‘freezing’ most of the vsti tracks in that reel- otherwise I get this error message somewhere on export (hopefully the beginning.) Freezing is a workaround but on subsequent reels where ‘previous’ reels sequence are left in tack (in case a cue needs to be reprised/revised) - this freezing can be VERY time consuming.
I have muted all previous reels (parts) but this doesn’t shorten the freeze by much.
I guess I have two questions - one for Steinberg - any solution / update close at hand for this ‘CPU spike’?
Users - another way to be faster on this workflow workaround?
This problem is starting to be a complete pain in the bum for me. Having to freeze loads of tracks just to export a mix is not good; it wastes acres of time and is an embarrassment when working with clients. I may be a bit thick but I assumed that as this did not happen in N4 it would be an easy fix and would have been solved in the last update. Presumably a work around would be to record a mix by coming out of N5 and back in on to a track, this is very messy and un-pro. The exporting function is important and should work. And it doesn’t help when clients ask why you have to WASTE THEIR TIME. Steinberg fix the f****ng thing I have paid good money for this program.
Martin, just so you know - you can choose your mixbuss as an input source for an audio track if you need to record your mix. No need to come outside nuendo. Just make sure the destination track is not routed to your main mix and the option will be available.
By way of comparison in case it helps you spot something, I’ve been doing these exports non-stop for the last few weeks on projects with about 100 tracks, lots of plugins (including a half-dozen reverbs at least) without any problems. I’m running a buffer size of 256, but most of my virtual instruments are hosted in Vienna Ensemble Pro (64-bit) Server. I have a couple instances of it going running dozens of Vienna Instruments and Kontakt. No hiccups on Snow Leopard.
Machine does have 16G of RAM and the project is running off an SSD drive. Video is also going Firewire out, not to onscreen player.
Thanks Sam,
I did know how to record back, but it is a pain to have to set it up, transfer the audio to which ever folder I’m using for mixes and if I just want to run an mp3 for evaluation…
I have gone back and tried N4 on export and it works fine, so I think it is N5 being naughty.
Also sorry for swearing in my previous post but I was fresh from export hell when I wrote it!
I need to use real time if I’m using my TC6000 (the only bit of real {if you can call it real} kit we have!) so I realy could do with this export thingy working.
Martin
Ever since N5 was released I have been battling CPU spiking that was not present in N4. Some of it appeared to be related to graphics as some of these problems went away (or at least lessened) when I hid tracks with certain shaded patterns/overlaps in folder tracks. I was often unable to record at low latencies in N5 on a very fast machine when N4 would have been coasting along. A fix was showed up in the 5.1.0 release that has now allowed low latency recording and has pretty much eliminated the CPU spiking caused by the display of overlapped audio events. I’m still experiencing what I consider to be unacceptable spiking of cores during saves and at seemingly random times, but things have improved in certain areas. The reason I am mentioning this is that during my quest to eliminate CPU spiking while tracking, it seems that the spiking on export problems I used to see every now and then have gone away. Just to clarify, I have been talking about low latency tracking etc., but the spiking on export problems I had experienced were with higher buffer settings.
I’m using a quad-core i7 system and ended up changing the BIOS setting so that the power saving features for the processor were disabled. The C1E, C3, C6, EIST should be disabled so that all cores run at the rated speed all the time - no throttling etc. I checked my DPC latency using the popular app and all was well (even before I made any changes), but I was able to improve things. One setting of interest may be the HPET (High Precision Event Timer), though I’m not 100% sure if disabling it is the correct thing to do - my DPC latency improved quite a bit with this turned off but I didn’t notice any improvement in actual performance and ended up finding information stating that the HPET should be enabled (despite slightly higher DPC numbers) to ensure better timing for MIDI etc. - it is worth experimenting with, however. I currently have the HPET feature enabled in my BIOS (causing a slightly higher DPC latency, but more than acceptable).
I have not had a single “CPU Spike on Export” since I made the above BIOS changes, though I admit it could be a coincidence (but it has been many months). Also, recently I discovered that I was seeing some spiking during record that was not present when just playing the tracks - which got me thinking that writing data to the drive was possibly causing heavy CPU load on one of the cores. I ended up changing settings for the disk caching in Device Manager which pretty much eliminated the extra CPU load when recording. I didn’t have the box checked that improves performance at the expense of possibly losing data during a power outage (I have a good UPS on my machine as we all should!) and enabling it appeared to have improved things quite a bit. It seems that when you have Windows force the HD cache to clear it can cause CPU spiking. After I discovered this I did some research and determined that I had installed Win 7 using the IDE mode for SATA when I should have used the newer AHCI mode instead. ACHI was NOT recommended for Win XP and could cause data loss which I was aware of during my previous build of my Win XP/Core 2 system years ago. With this knowledge I used IDE to be safe when I built the new i7 computer last summer and was not aware that with Windows 7 AHCI should be used. Luckily, I was able to find a method to enable AHCI after the fact (you normally need to enable it in the BIOS first before you install Windows) by editing the registry and then changing the BIOS to “AHCI” during the next reboot. Things do seem to be running better in AHCI mode, but it has only been a week or so since I made the changes.
Sorry for the long post, but I’m hoping that this information may help some of you to at least reduce the amount of problems you are having with CPU spiking and possibly even solve it all together. It shouldn’t be this difficult and if these settings are that critical to simply exporting a file, then support should be aware of it and informing us on how things should be configured. That said, I still feel that N5 has issues with resource contention that need to be addressed - and sooner NOT later.