Jump to content
mdiemer

(UN-RE-SOLVED)Saving Project Is Suddenly Very Slow

Recommended Posts

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 by mdiemer

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by mdiemer
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
50 minutes ago, mdiemer said:

Fortunately, the fix is easy: Just restart periodically.

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

Share this post


Link to post
Share on other sites
5 hours ago, Promidi said:

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

restart is more complete than logging off

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Posted (edited)
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 by mdiemer

Share this post


Link to post
Share on other sites
Posted (edited)
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 by mdiemer

Share this post


Link to post
Share on other sites
Posted (edited)

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 by mdiemer

Share this post


Link to post
Share on other sites

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. 

  • Like 1

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...