(SOLVED)Saving Project Is Suddenly Very Slow

[mdiemer]

I am working on one of my orchestral projects, and lately when I save it, it seems to take forever. It used to save very fast. Could the project have been corrupted? If so, what should I do about it?

I am not using the latest CbB, being of the "if it ain't broke don't fix it" school; but it's fairly recent (2019.09). Also I am using Windows 7. I rarely go online with this computer, but I use Malwarebytes Premium just to be on the safe side. Could that have something to do with it?

Edited March 25, 2021 by mdiemer

[M.O.S.T. Music]

Try "Audio Folder Optimization" https://www.youtube.com/watch?v=LfwMIspOxoo&t=44s

Check it out. It may help

[mdiemer]

On 2/22/2020 at 7:11 AM, pwalpwal said:

tried scanning the HD for errors/fragmentation ?

Thanks for the suggestion. I checked it though and it's not fragmented, so that wasn't it.

[mdiemer]

On 2/22/2020 at 12:16 PM, M.O.S.T. Music said:

Try "Audio Folder Optimization" https://www.youtube.com/watch?v=LfwMIspOxoo&t=44s

Check it out. It may help

That did help, thanks. I do midi so I don't really have much audio, but just running the utility, and deleting two large files in Recycle Bin that I didn't need, has improved saving time considerably.

Edited February 24, 2020 by mdiemer

[mdiemer]

I know I marked this solved, but the problem returned. However, I think I know now what it is. So, in case this applies to anyone else, I don't shutdown my computer completely most of the time, I just suspend. That way my large orchestral projects load much faster. But this seems to eventually cause slow saving for some reason. Fortunately, the fix is easy: Just restart periodically.

[Promidi]

50 minutes ago, mdiemer said:

Fortunately, the fix is easy: Just restart periodically.

Would logging off, rather than the full restart, be enough?

[bitflipper]

Rebooting is the only way to fully reclaim allocated memory. What you've probably been seeing is the result of gradual memory loss (not yours, your computer's) that inevitably occurs over time. If you have a lot of RAM it may take weeks before the problem becomes noticeable - unless you're running extremely memory-intensive applications.

This happens with all operating systems, but Windows has historically has been particularly guilty of memory leakage issues. I remember it being discussed a lot when Windows 3.0 came out. Back then a typical system might have only 4 MB of RAM, so memory management was something you had to be cognizant of. Nowadays we have so much RAM we can be pretty sloppy, leaving the computer running for months at a time and rarely if ever checking memory usage. So if you currently have 16 GB, doubling that to 32 GB should let you go longer between restarts. 

 

[mdiemer]

10 hours ago, Promidi said:

Would logging off, rather than the full restart, be enough?

Not sure, but it does help when a project won't open quickly for some reason. What I mean is, sometimes I work on a project, close it, and try to open another one immediately, but nothing happens. Logging off and on does help in that case.

[mdiemer]

5 hours ago, pwalpwal said:

restart is more complete than logging off

True, so it may be that logging off helps some problems, but not others.

 

Edited March 28, 2020 by mdiemer

[mdiemer]

3 hours ago, bitflipper said:

Rebooting is the only way to fully reclaim allocated memory. What you've probably been seeing is the result of gradual memory loss (not yours, your computer's) that inevitably occurs over time. If you have a lot of RAM it may take weeks before the problem becomes noticeable - unless you're running extremely memory-intensive applications.

This happens with all operating systems, but Windows has historically has been particularly guilty of memory leakage issues. I remember it being discussed a lot when Windows 3.0 came out. Back then a typical system might have only 4 MB of RAM, so memory management was something you had to be cognizant of. Nowadays we have so much RAM we can be pretty sloppy, leaving the computer running for months at a time and rarely if ever checking memory usage. So if you currently have 16 GB, doubling that to 32 GB should let you go longer between restarts. 

 

As for the memory loss, I got both kinds, Bitflipper. Like many of us old Cakewalk guys here. As for Ram, I do have 32 GB. 16 was not enough, upgrading to 32 did help substantially, especially with things like clipping and distortions. 

I'll keep in mind the need to restart periodically. I'm sure weekly would do it, but I'll probably let it slide, like I do most things....

Edited March 28, 2020 by mdiemer

[mdiemer]

I did some experimenting. Hibernating results in the slow load times, just like sleep. I also realized that hibernation is what happens when I have a power failure. When I start up, it takes forever, and I think my system is borked, but then it eventually does start.  I don't know if hibernating is the default action for W7 Pro in case of poer failure, or if I had it set to hibernate when I push the power button. I decided to set it to "do nothing" when power button is pushed, as I use the start menu to shutdown, log off etc.

Edited March 28, 2020 by mdiemer

[bitflipper]

Hibernation puts your computer back into the exact state it was in prior to sleeping, restoring the entire contents of memory. Including any wasted memory and unneeded background processes. Only a hard reboot gives you a clean slate. Yes, it takes longer to get going initially. I just go make a pot of coffee. 

I'd try to discover which virtual instruments are taking the most time to load/save. Unfortunately, there is no easy way to do that other than the painstaking process of saving and restoring different versions of your project with different instruments deleted from it. However, logic dictates that the largest memory consumers will likely be the prime culprits, and you can find out that information from Kontakt.

I have identified instruments in past projects that gobbled insane amounts of RAM even though they played a small role in the composition, and those are the first things to get frozen. A frozen instrument has zero load time. Granted, I often have to un-freeze some of them later to tweak the composition, but in the meantime I can enjoy very fast loading times while working on other stuff.

One thing I avoid doing is loading a lot of instruments into a single instance of Kontakt. Yes, doing so does save some CPU, but it makes freezing and un-freezing more time-consuming. Separate Kontakt instances for smaller groups of instruments gives you finer granularity when deciding which tracks to freeze. So while it may make perfect logistical sense to combine a whole orchestra into one instance, chances are there's a piccolo flourish or a tambourine hit that you won't need to edit and can therefore be moved into its own instance and frozen.

Same idea goes for Omnisphere, an even worse memory hog than Kontakt. I've had slow-loading projects suddenly speed up after freezing a single Omnisphere instance. Non-sample-based synths are never a problem, so I'll often try Zebra for percussive hits and bells over Omnisphere. It might not have the same tonal complexity, but if it works in context that'll be one track that won't slow me down.

Are you using an SSD for audio/samples? The newer NVMe drives are so frickin' fast it's almost like reading/writing to memory. I don't have one yet, but I'm just waiting for prices to fall some more. Unfortunately, I have over a Terabyte in just Kontakt libraries alone, so moving them to an NVMe SSD will be expensive. 

[mdiemer]

2 hours ago, bitflipper said:

Hibernation puts your computer back into the exact state it was in prior to sleeping, restoring the entire contents of memory. Including any wasted memory and unneeded background processes. Only a hard reboot gives you a clean slate. Yes, it takes longer to get going initially. I just go make a pot of coffee. 

I'd try to discover which virtual instruments are taking the most time to load/save. Unfortunately, there is no easy way to do that other than the painstaking process of saving and restoring different versions of your project with different instruments deleted from it. However, logic dictates that the largest memory consumers will likely be the prime culprits, and you can find out that information from Kontakt.

I have identified instruments in past projects that gobbled insane amounts of RAM even though they played a small role in the composition, and those are the first things to get frozen. A frozen instrument has zero load time. Granted, I often have to un-freeze some of them later to tweak the composition, but in the meantime I can enjoy very fast loading times while working on other stuff.

One thing I avoid doing is loading a lot of instruments into a single instance of Kontakt. Yes, doing so does save some CPU, but it makes freezing and un-freezing more time-consuming. Separate Kontakt instances for smaller groups of instruments gives you finer granularity when deciding which tracks to freeze. So while it may make perfect logistical sense to combine a whole orchestra into one instance, chances are there's a piccolo flourish or a tambourine hit that you won't need to edit and can therefore be moved into its own instance and frozen.

Same idea goes for Omnisphere, an even worse memory hog than Kontakt. I've had slow-loading projects suddenly speed up after freezing a single Omnisphere instance. Non-sample-based synths are never a problem, so I'll often try Zebra for percussive hits and bells over Omnisphere. It might not have the same tonal complexity, but if it works in context that'll be one track that won't slow me down.

Are you using an SSD for audio/samples? The newer NVMe drives are so frickin' fast it's almost like reading/writing to memory. I don't have one yet, but I'm just waiting for prices to fall some more. Unfortunately, I have over a Terabyte in just Kontakt libraries alone, so moving them to an NVMe SSD will be expensive. 

Thanks for all that great info. Fortunately I only need to use one Kontakt instance, with just 5 instruments on it (Cinematic Strings). That loads quite fast. The hogs are East West Play, and especially the Vienna Ensemble player. Still, my projects load in about 5 minutes, but in our time-conscious, instant gratification mindset, that seems like an eternity. And I don't have any games on this computer; I don't want anything to divert me from working. So I either sit and twiddle my thumbs, or watch a few minutes of whatever game is on TV. Which is, of course, these days just reruns of Tom Brady super bowls, which I have already seen too much of (although I live in Maine, I'm a Pittsburgh Steelers fan.

I've never frozen an instrument, but that's a good idea. I do have a tambourine and triangle on the Vienna Player, and Cymbals on Play. They could certainly be frozen as I rarely need to adjust them. I also do follow your advice in assigning simple percussion instruments to less resource-Hungary synths. In fact, I usually just use the Garritan stuff, it's decent and the Aria player loads in seconds. On this project however I needed more oomph for them as there's a lot going on in this piece.

As for SSD's when I finish this project I was thinking of getting one for the C drive. however, the WD Black hard drives on this rig, though 6 years old, continue to perform perfectly, so I may just wait until they die. Or I could get SSD's up and running and use the others as backups, I guess. I do plan on updating the Play synth before my next project, in case that improves load times for my EW instruments (EWSO Gold).

[bitflipper]

I'd suggest getting an SSD for your samples before replacing the boot disk. When I replaced my C drive with an SSD, the speedup was disappointing. Noticeably faster, but not life-changing. That's because most of what happens on your C drive is of a transient one-time nature, e.g. loading programs. Cakewalk and other applications start up quickly, but projects take just as long to load. Where the SSD pays for itself is when reading audio data.

[mdiemer]

Thanks again Bitflipper. I'll have to bite the bullet at some point. It's not so much the price, it's more the hassle of all I have to do to get several orchestral libraries up and running, not to mention reinstalling Windows.

anyway, I did a little research on slow-saving in Windows 7, in general, as the problem has returned. One thing that caught my eye was that saving on USB drives can result in corruption. In fact, I had been doing that, and now seem to recall that the slow-saving may have started then. So I went back to my old Glyph external drive. now I'm wondering if that too is suspect.

I did some things to try to improve the situation yesterday, and ended up making things much worse. I had to do a system restore, and in safe mode at that. Now things seem fine, and the project is saving OK, but I'm afraid to use the Glyph now.  I may go back to using a CD. Or I could save a copy on the D drive, which has my samples. It's a 1 TB drive so there's plenty of room.

Anyone have any thoughts on these ideas?

 

[mdiemer]

An update on this: it seems that saving anywhere other than C drive brings on the slow-saving gremlin. Oddly, if I rename the piece, then it starts saving normally again. No clue what that's about, but it is a workaround, albeit a rather weird one.

[mdiemer]

I may have solved this, or at least found one big reason why it's been happening:  My large orchestral projects have many instruments, and in the clips pane there are all these white thingies all over the place. I'm not sure what they are, but they go away when I do "bounce to clips." And then the project saves normally. 

Old thread I know, but I just wanted to tie it up, in case anyone else might have this problem. 

Edited March 25, 2021 by mdiemer