6.5 - Why is saving still so slow?

Update:

Started a new project yesterday… Something simple… 70ies Metal, recorded more or less live… so - very very basic editing only, not much tracks - currently just a handfull of plugins… Started in N6.5 (using a 6.0 template though)

Manual saving is done in a fragment of a second.

Autosave CAN took 20 sec… I know this is strange but sometimes it is fast as the manual save - sometimes it “freezes” for 20 or even more seconds - I was frightened in the first moment because I thought of a Nuendo Crash/Freeze.

I have NO offline processing, NO timewarp/vari-audio in it.

We’ve hit long save times here as well. We have two different machines (both are mac, though) and are using 6.5 on each. One project has 256 files but each file is almost 3 hours 26 minutes long. There is also a video file attached of 1 hour 13 minutes. One plugin running. No foolin’ this thing takes almost ten minutes to save.

Is Nuendo re-writing the audio image files every time it saves? I ask because I got rid of the peak file folder and let it make them again and that’s taking that kind of time.

I also have another project that has 24.4 thousand files in use of varying different lengths spread out over around 2 and a half hours. This also take 5-10 minutes to save.

Help!

Thanks!

Darren “Time On My Hands” Ingram

Update on our project. We’ve been doing a bit of editing and the project now takes about 15 minutes to save. This is the project that started with 256 files each 3 hours 26 minutes long. The whole project contains 403 gigs of data.

The machine this is on a mac pro with 8 cores, 2.26mhz, 32 gigs of ram, internal spinner drives, Mavericks, N6.5.

Help!

Darren “15 Minutes Later” Ingram

Hello Darren

I can’t help it to say that such a project with this number of files and the mentioned length
is bound to produce long safeing times and all sorts of other problems.
Why don’t you split it in reels and put them together in the end?
The extra work should be compensated with the shorter safeing times…

I mean, there is a certain natural limit to what a DAW can handle, these days, before it gives in.
In fact, I find it amazing that it only needs 15 minutes… and obviously produces no errors during safeing.
For me that project would be much to dangerous and to cumbersome to work with, as it is now.
M2c, …

Cheers, Big K

Have you disabled hit point detection and deleted all hit points on all events in the project?
Hit points and automation and process history data are regular save time issues in N6.5.

Excellent idea! Will try.

Thanks!

Darren “Slave To The Save” Ingram

Ok, gave the hotpoint data thing a shot but I still have issues with massive save times. I’ve been watching my mac’s Activity Monitor and when saving, the Nuendo process reports as Not Responding.

I’ve also watched the data IO while it’s saving and it barely registers any data movement at all, if any. I just now watched the data monitor sit at 0k data movement both in and out for around 30 seconds while saving until a quick burst of around 700k was written, then back to 0k for 30 seconds or so until another quick burst of around 700k, then back to 0k.

Also, the CPU is sitting at 91% idle. this is an 8 core 2.26ghz machine with 32 gigs of ram.

It just doesn’t seem like there’s a whole lot happening while I’m saving. But it still takes around 30 minutes to save. Even if I hit save immediately after a previous save, it still takes this long. And again, I’m not seeing massive cpu usage or disk usage.

Hmmmm…


Darren “Watching Paint Dry” Ingram

Darren i have some theories.
Basically I agree, there are major issues or flaws in how Cubendo handles the saves.

Generally the main issues with save times seems to be large amounts of any or several of the following:
Automation
Process history data
Amount of files in the project
Vari audio data

In my case it’s mostly process history data and automation data that causes slow saves.

You can test this by for example:
Freezing all edits ( don’t do it on the original project as it is not undo able reliably).
Delete all automation in project.
Flatten all vari audio events.
Reduce the number of files in the pool.

None of these are really solutions, just possible routes to show where you’re personal save time issues lie.

Some possible help on the way:
If it is caused by automation you can reduce the amount of automation in various ways.
You may be able to freeze some edits or flatten some or most vari audio data.
You may be able to split the project in multiple parts to keep the number of files lower.
Any or all oft he above without to severely affecting your workflow.

But yes the issue is bad and has to be resolved by Steinberg for real.
Especially as for most users it will be a combination of all these things causing the slow save times.

Does the same issue exist in Cubase? I didn’t see anything about it in the forum for Cubase 7.

I find that the long save/auto-save is the biggest downer with Nuendo. On larger projects, having to wait for Nuendo to “catch up” is a creativity killer. As one client has said during wait times “Nuendo is thinking”. Turning off auto-save is not an option, even though Nuendo is pretty stable.

Dean

SOLVED!!! (At least for me…)

OK, I was wrong earlier. My problem WAS having hitpoint data.

We thought we had cleaned out this data but I don’t guess we did.

One quick addendum: I thought that I had cleaned all my hitpoint data and I was still getting high save times. So I made sure automatic hitpoint detection was turned off in my prefs, I exported my entire project using Export Selected Tracks. I imported that XML file into a clean project and my save times were down to 8 seconds.

On my big project:
Save time WITH hitpoint data: 3.5 HOURS!!!
Save time WITHOUT hitpoint data: 8 SECONDS!!!

Whoo hooooo!!!

Darren “Back In Business” Ingram

I never had a problem with this autosave beachball thing in the years since Nuendo 3.

I recently disastrously updated to Yosemite and had to go back to Mavericks via the Time Machine backup, it is only since this, I have the slow save problem and also I have parallel drum compression busses which are now phasey.

If this gives anybody any ideas - please post them up as soon as poss. I’m so gutted I’m right in the middle of tonnes of work and this is really slowing me down!

Hi there,

same problem with extended saving times here.
It takes Nuendo 4 minutes to save a 90 min. project with 10 tracks.
No plug In’s running, no automation just plain audiofiles, cuts and fades.

I have tried the above mentioned tricks with hitpoints etc. but they do not work for me.

The saving times increased along with increasing use of effects and plug-in’s.
However, nothing changed from rendering the effects into the audiofiles via archiving…

Does Nuendo “remember” the use of plug-in’s and effects somewhere?

Cheers,
David

Dear all,

my problem is solved now.
Darren got back to me with an exact advice on how to remove the hitpoints:

  • go to your preferences and under Editing/Audio make sure the “Remove Regions/Hitpoints on all Offline Processes” is checked. Also, in that same area, make sure “Enable Automatic Hitpoint Detection” is unchecked.

This is what I did before, but the thing that made it work out was:

  • select all audio and use the “remove hit points” command.

I checked this thread again and saw it was already pointed out earlier by Erik G, but I must have skipped that.
For those who still have the same problem try the other advice of Darren:

  • select all tracks and then choose Export - Selected Tracks. We simply referenced the files, we didn’t copy all of them.
  • Make a brand new project then select Import - Track Archive.

Hope this helps!
Thanks a lot Darren and Erik!!

Cheers,
Davrus

Hey Get This!

I changed my Time Machine disc in my Mac and hey presto - near instantaneous saving time!

I’m sure it doesn’t apply to you windows users, but this might mean something to Mac users

Tidy!

no one find issue ? it’s amazing … nuendo is one of the most expensive daw on the market , and basic save / auto save in the background can’t work properly. What is more important to save the perfomance that’s the musician did when you recording ?

steinberg please ? any info ? will you fix it ? when ? what can we do ?

thank’

Have you tried the tips in the thread?

Check amount of automation, hit points and offline history data?

Whenever I notice saving times are getting longer I check for unnecessary material (older projects, etc.) and remove them to free up more space. After that saving times are usually back to normal. Might have something to do with using SSD drives and TRIM not working properly.

Cheers, Martijn.

Just to report… having long saving times (not long as some of you but still…), 10 sec or so, for saving empty project, with no audio, midi events, nothing. Just loaded my template with around 40 Kontakt instances full of instruments ( every instance with 8-16 instruments, samples all purged). Around 250 midi tracks, around 100 kontakt outputs.

I did some testing…all those instruments loaded in Kontakts are the reason for long save time. If I unload them, and leave all kontakt instances empty, all the midi tracks, audio outs and all plugins (every audio out has instance of virtual scoring stage 2) stay as well, instant saving time are back.

I see VE Pro as obvious solution for this, but… is this really necessary? I feel like the reason for my long saving times is the same as all of the users are reporting.

Is C 8.05 resolved saving time for all of you from this thread?

Just as a sort of update to Hitpoints and Save Time (and file size of XML and csh) as I think it is very important to know especially for postproduction editors.

I have being struggling with a Nuendo session having very long save time (up to 70 sec). It being not more then the Production Sound of a 75 min documentary I was wondering what is special in this project. The only point that made sense regarding save time was the very long audio files that are used in this session (quite a few with 60 up to 120 min.)
Just for a test I did a back up project with reducing audio files to clip length….and yes, save time now was so short you could not even feel it.
Now back to the real project. I had to do a XML export of it. XML of this 40 MB session came out at around 600 MB. I sent this xml to a friend who is into writing code to take a look at it. He found that the text of this XML is 99% about HITPOINTS.
I remembered then the posts in this thread and turned of Hitpoint Detection.
But obviously once that session was open with Hitpoint Detection ON……. the damage was done. For every clip in that session loads of hitpoint information having been written. And, as it looks like, not only for the part of audio, that is used in the track, but for the whole length of the audio.
After having removed all hitpoint information from that session through “audio-remove hitpoints” I had the following results:
Save time before: 30 sec. Save time now: less then 1 sec (actually unremarkable)
Project file: before 40 MB, now 10 MB
XML of tracks: before 600 MB, now 27 MB
.csh file of session: before 350 MB, now less then 1 MB

Oswald