I am confused with the 1 minute save part... the cwp only saves pointers to underlying audio files (which are already saved). The only part that I do not do is retain each and every take, so you have more pointers in play than I would, but I would still assume they are all in RAM with the project you are working on, so taking 1 minute to save a 4.43MB file seems "out there."

Perhaps your laptop HDD IS 5400rpm.

mudgel
Perhaps your laptop HDD IS 5400rpm.

 
Nope, it's 7200rpm. I checked Sonar system requirements before buying this laptop.
 
 

Noel Borthwick [Cakewalk]
Regarding slow saves its most likely instruments that take long to save although lots of audiosnapped clips are also known to slow down the save process.

 
I have several 4 minute-long audio clips that were bounced after being slip-stretched with Audio Snap enabled. I'm not sure if these clips are contributing to the long saving time. As for instruments, my projects don't use huge libraries. All of my projects created from my custom project template that contains many empty tracks and some instruments/effects doesn't take a long time to load (except for the initial launch after a PC restart), but the saving time seems to increase more and more as I record and comp (and probably slip-stretch and bounce) more audio clips.
 
 

Noel Borthwick [Cakewalk]
If you typically run at low latency and have lots of instruments one thing you can try is adding the variable "PauseDuringSave" to the Cakewalk.ini file. In preferences | File | Initialization file PauseDuringSave and set its value to 1. Restart SONAR after that and you should see that the application pauses audio during a save. This allows the save to complete faster since its not being interrupted by audio engine access.

 
Will definitely try it. Thanks!  

Noel Borthwick [Cakewalk]
We wouldn't want SONAR interrupting the worflow to do a save since in big projects with large samplers etc saving can be costly. Its simple enough to turn on autosave when you need it.

 
For years I left auto-save on all the time because I mostly mix recordings where the project file just contains FX, FX params and some automation and clip data. This data is small and saves in seconds.
 
I understood why it isn't on by default when I started recording my midi guitar regularly in projects. The size of the project file would explode from a MB or two to 20. saving a 20 MB file takes a while and doing it once every 3 minutes doesn't make sense. I regularly record a couple of hundred takes on each part of the song.
 
I've often thought that keeping most recent 20 saves might make sense where I trigger the saves. I use ctrl+s or alt+F+S for a long time (I've gotten away from alt+F+S because it doesn't work properly in Console View.). It's nice to be able to go back 5 versions to recover something that changed by accident ~ EQ settings gone wrong... something like that.
 
I keep a bunch of versions and use AutoSave when I'm working in smaller projects. I don't leave it on all the time though. And it's probably less than once a year that I hunt back through the autosaved versions for a different save point.

mettelus
 
DOH! I wish I had known this 6 months ago trying to find the "errant AS" in a project.

Same here!!

Just tried the following with all tracks visible in the TV/CV:
 
 
Deleted all slip-stretched auido clips, then saved the project under a new name.
--> Project folder size decreased from 1.90GB to 1.73GB. Saving time decreased from 55 sec. to 52 sec.
 
Deleted all soft synths (AD2 & two instances of Kontakt 4) without deleting the associated tracks, then saved the project under a new name.
--> Project folder size remained the same (1.73GB - but strangely increased to 1.74GB just after I did the following step). Saving time increased from 52 sec. to 65 sec.
 
Deleted all effects (too many to list), then saved the project under a new name.
--> Project folder size remained the same (1.73GB). Saving time increased from 65 sec. to 70 sec.
 
Deleted all track automations, then saved the project under a new name.
--> Project folder size decreased to 1.72GB. Saving time decreased 70 sec. to 65 sec.
 
Deleted all MIDI clips, then saved the project under a new name.
--> Project folder size remained the same (1.72GB). Saving time decreased from 65 sec. to 52 sec.
 
Unlocked all audio clips and cleared all audiosnap markers (just in case I still have them), then saved the project under a new name.
--> Project folder size remained the same (1.72GB). Saving time remained the same (52 sec.)
 
Deleted all auido clips, then saved the project under a new name.
--> Project folder size decreased from 1.72GB to 1.36MB (Audio folder is 0 byte, of course). Saving time decreased from 52 sec. to 12 sec.
 

From these results, I can say it's the size of audio (perhaps the number of audio clips in Take lanes - which have LOTS of split points) is the culprit of long saving time.

The joy in Autosave is when the .cwp get corrupted and the "Copy of......".cwp is valid.
 
This has saved me hours of reconstructing of at least once project per release since I implemented it back in X1.
 
Yes, it would have been better to discover what the source of the corruption but since it's only been about four or five projects I'd rather just carry on by opening the autosave project and overwriting the corrupted project with a Save As.

My saves, exports and pretty much everything takes longer when I have a mountain of takes and the grows massively with intricate comps in play. I can really say whether Flattening helps at all but I haven't noticed any significant improvement after doing so for most stuff (might be quicker for saves and exports).
 
The #1 thing that improves the speed of EVERYTHING in my project is copying my final, flattened take to a cloned track and archiving the take laden original version.
 
If I do this across the entire project I go from a project that...
 
Takes a second or more to begin playback to a project that starts playback immediately
 
Makes what I THINK is what is referred to as "zipper noise" when jumping the Now Time to another location during playback into one where no noise occurs when doing so
 
Exoprts slowly (sometimes more slowly than real time bounce when Fast Bounce is selected) to one that exports quickly
 
Saves slowly to one that saves quickly
 
Is glitchy to one that is less glitchy
 
etc...
 
This is why I posted a Feature Request recently for us to be able to bulk archive Take Lanes. So you'd Flatten your final or multiple finals and archive all the other take lanes to remove them from processing. This avoids having to do my little "Clone/Archive dance every time I finish a track". Go vote for it.
 
I did however forget to include in that FR something I've been asking for since X2 which is a "Hide Take Lane" feature so I don't have to look at those piles of takes when I've got my finals but don't lose them or have to clone, archive and hide them the old fashion way.
 
Meh. Would make things much easier for me and I seriously think this is the type of stuff that might improve stability for take maniacs like myself... thus less complaints on the forum.
 
Just push it as part of the standard/recommended workflow and I'd bet people would be a lot happier with Sonar. Seriously the improvement is like night and day when I do this stuff... but it's a time consuming PITA especially on large projects.
 
Cheers.