This problem has been bugging me and lots of my fellows for decades. The saving takes a long time and the whole application just stuck there.
I get it, some third-party plugins take a long time to save. But it seems to me that they have not stopped responding during saving because I can hit play then hit save and it’ll keep playing without interruption during the saving process. That’s been what I’m doing for a long time - use the listening back time to save.
So is it possible not to freeze the whole app while saving - saving in the background? Especially during auto-saving?
Yes, this has been one of my Annual Requests. My proposed solution is that Cubase should behave a bit like the Follow command–it should ‘sense’ when you’re doing something and -not- auto-save.
My suggestion is that the program should wait for a lull in keyboard and mouse activity of perhaps 5 seconds before auto-saving.
What drives -me- nuts is when it just decides to auto-save during playing while I’m actually moving the mouse around to make an edit.
Giving that it’s the plugins that cause longer saving time, and Cubase is able to detect whether changes have been made to a plugin, it only needs to save those with changes .
For those without changes, simply copy that part of info from the last saved project. Most of the time, especially during composition, there aren’t many changes on the plugins. Changes mostly happen on the tracks and mixers. There’s no need to save all plugin information every time it saves. It may largely reduce time cost on saving.
But ultimately, it need to be solved by a new way of saving. Do you have to freeze the application when savin? Is it because changing during saving would make the project inconsistant?
If that’s the case is it possible separate the plugins and project during the saving process?
e.g. devide the saving into 2 steps:
1, freeze the whole project and save the non-plugin related info. Since no plugin’s involved this step should be very fast.
2, de-freeze those already saved part of the project to allow play back and editing, leaving the plugin-related stuff remain freezed from editing, then save those. Since non-plugin related info are saved in step 1, further editing would not make saved project inconsistant.
That way at lease the work can go on with much less interruption.
Steinberg, please allocate some manpower on re-writing the saving machanism before developing new fancy features. Users would appriciate that!
Wanted to bump this. Im on a m.2 NVME SSD, intel 12900k, and the thing still takes 45 seconds to save, 55 seconds on external drive, (45 seconds if I use the ultra speed NVME drive that writes at 5000 MB/s). Why can’t we optimize this? If it weren’t for the save times there would be no need for Vienna Ensemble Pro anymore. The big bottleneck seems to be Kontakt specifically, since some other VSTs don’t have the same footprint. The session size itself gets massive as well (1GB+ .cpr file)
+1 on save times being a big reason why we really need VEP still (though loud times would be other big reason).
What will really blow your mind is if you disable all of your Kontakt tracks - even those tracks with tons of data and automation - your save times will drop to almost nothing.