What causes bounces to slow down?

[philbrown]

I do the same kind of work, week in and week out. It involves regularly bouncing down hour-long stereo files. I use the same procedure, the same plug-ins, same computer, etc- everything remains pretty constant, but my bounces have slowed down. I never timed them, but since I've done this work for many years I have a sense of how long they take and it seems these days they're taking maybe 30-40% longer than they used to. The only change I can think of that I made recently was switching from a Firewire 800 Apollo interface to a USB 2.0 Midas M32R board. Doesn't seem like that would be related but maybe it is. My internal SSD data drive has plenty of space and I haven't changed out any other software, hardware, drivers, etc.

Your thoughts?

[MIDI Life Crisis]

Depends how n the bounce. Bouncing to project format always seems fastest, probably because no conversions are processing. MP3 bounces can be sped up by messing with the settings a little. Also the number of tracks, plugs, VI script processing, misbehaving 3rd party stuff, inclusion of muted tracks, etc, all add to the bounce time.

If the files and plugs being bounced are identical or very similar yet bouncing to the same format yet take longer, then it could be a drive busy with Spotless indexing (or failing) or RAM getting consumed by any other app/process/memory leak. May also be a data flow/CPU blockage caused by any process running and pulling resources.

It could also be gremlins!

[philbrown]

Depends how n the bounce. Bouncing to project format always seems fastest, probably because no conversions are processing. MP3 bounces can be sped up by messing with the settings a little. Also the number of tracks, plugs, VI script processing, misbehaving 3rd party stuff, inclusion of muted tracks, etc, all add to the bounce time.

If the files and plugs being bounced are identical or very similar yet bouncing to the same format yet take longer, then it could be a drive busy with Spotless indexing (or failing) or RAM getting consumed by any other app/process/memory leak. May also be a data flow/CPU blockage caused by any process running and pulling resources.

It could also be gremlins!

Thanks! That's the kind of ideas I was looking for. I've got a couple of things I can try differently to test for some of the things you mentioned. The projects are all the same though: bouncing to project-format 16 bit stereo interleaved wav files with the exact same plug-ins.

[Tritonemusic]

Is it possible that some sort of background processing is going on (unrelated to DP) that may be slowing things down? Have you installed anything recently that may coincide with the slowdown? Unfortunately, that's all I've got...

[philbrown]

Is it possible that some sort of background processing is going on (unrelated to DP) that may be slowing things down? Have you installed anything recently that may coincide with the slowdown? Unfortunately, that's all I've got...

Not that I can think of, and today I made sure to close all the other apps (usually just a browser and email). Next bounce I'll do a restart just before bouncing just to clear everything out. And then try looking at the console as well. I'm also clearing out my SSD today, just for good measure- it was about 3/4 full.

Thanks!

[MIDI Life Crisis]

It doesn't have to be a running app. Spotlight indexing can really slow a drink be to a crawl, as can a massive download in progress, etc.


Sent from my iPhone using Tapatalk

[mikehalloran]

Try purging RAM first. A reboot is one way to do that. Quitting other apps does not always release available RAM.

[mikehalloran]

Try purging RAM first. A reboot is one way to do that. Quitting other apps does not always release available RAM.

I didn't mention the following Terminal command since I have never tested it in El Cap but it still works and only takes a second to run:

sudo purge

A lot faster than a reboot.

This got me curious so I tested a few things. As I have mentioned, my default browser is Chrome and I have a minimum of 115 tabs open in three browser windows on three monitors. I also have 20G RAM on my 2010 iMac i7.

This is what I found using TechTool Pro and sudo purge in Terminal. I quit and restarted TTP in between each test as it made a difference—it can only test available RAM which made it ideal for this purpose.

With 129 tabs open in Chrome (Mondays are my leanest days), I only had 488mB of RAM available for testing in TTP. Running sudo purge, I now had 1.48G available. Quitting Chrome gave me 15.38G available and running sudo purge again increased it to 15.50G (since I had already run it once, no surprise). Next I quit email and this made no difference—till I ran sudo purge again which freed up another 1.81G. Quitting Messages, likewise, freed up no RAM till I ran sudo purge and another 1.12G became available.

Do not jump to the wrong conclusions. None of this indicates a bug in the OS or memory leaks. Like cache, this is designed to make your Mac run faster. If however, you are going to run RAM intensive tasks, sudo purge is your friend and way, way faster than a reboot even with an SSD.

My wife was complaining about Office 2008 freezing up this morning but, when I went to look at it, things were fine. She has fewer browser windows open in Safari but her 2011 iMac i5 has only 4G of RAM. I don't even need to run a bunch of tests to know where the problem is. I am no longer under the impression that it's enough.

The only question is whether I order more RAM from OWC or from MemoryX (10 miles away).

I want to add that errors during Bounce to Disk and cloning failures are my two benchmarks that indicate bad RAM. Probably not the issue here but any kind of bounce wants as much RAM as it can acquire from the System during the process.

[HCMarkus]

I use the same procedure, the same plug-ins, same computer, etc- everything remains pretty constant, but my bounces have slowed down.

A wrinkle in time? Or VI's stealing more system resources?

[Shooshie]

I don't know the answer, either, but I suspect that once DP9.1 comes out, you'll see an increase in speed there. I think it's a combination of glitches and inefficiency in the Bounce feature. the same thing that's causing it to miss fades may also be causing the slow-down. But once they fix these things, I believe Bounce to Disk will be mind-glowingly fast.

I hope I'm right! (wouldn't that be wonderful?)

Shooshie

[philbrown]

Try purging RAM first. A reboot is one way to do that. Quitting other apps does not always release available RAM.

I didn't mention the following Terminal command since I have never tested it in El Cap but it still works and only takes a second to run:

sudo purge

A lot faster than a reboot.

This got me curious so I tested a few things. As I have mentioned, my default browser is Chrome and I have a minimum of 115 tabs open in three browser windows on three monitors. I also have 20G RAM on my 2010 iMac i7.

This is what I found using TechTool Pro and sudo purge in Terminal. I quit and restarted TTP in between each test as it made a difference—it can only test available RAM which made it ideal for this purpose.

With 129 tabs open in Chrome (Mondays are my leanest days), I only had 488mB of RAM available for testing in TTP. Running sudo purge, I now had 1.48G available. Quitting Chrome gave me 15.38G available and running sudo purge again increased it to 15.50G (since I had already run it once, no surprise). Next I quit email and this made no difference—till I ran sudo purge again which freed up another 1.81G. Quitting Messages, likewise, freed up no RAM till I ran sudo purge and another 1.12G became available.

Do not jump to the wrong conclusions. None of this indicates a bug in the OS or memory leaks. Like cache, this is designed to make your Mac run faster. If however, you are going to run RAM intensive tasks, sudo purge is your friend and way, way faster than a reboot even with an SSD.

My wife was complaining about Office 2008 freezing up this morning but, when I went to look at it, things were fine. She has fewer browser windows open in Safari but her 2011 iMac i5 has only 4G of RAM. I don't even need to run a bunch of tests to know where the problem is. I am no longer under the impression that it's enough.

The only question is whether I order more RAM from OWC or from MemoryX (10 miles away).

I want to add that errors during Bounce to Disk and cloning failures are my two benchmarks that indicate bad RAM. Probably not the issue here but any kind of bounce wants as much RAM as it can acquire from the System during the process.

Thanks for that, Mike! Good info.

[FMiguelez]

That Terminal RAM purging trick is awesome, Mike Halloran!

Thank you.


The Purge begins...

[philbrown]

Ok, so I started a bounce and (unscientifically) got a rhythm of how fast it was going. I had DP, Firefox, Safari and Mail open. I checked activity monitor before that and it was showing in the 6 GB range being used (didn't think to note it down), out of 20 gig RAM. I quit all the apps except DP and activity monitor and it was at 5.97. Ran sudo purge and it dropped to 3.24 GB. Restarted my bounce and it's going noticeably faster, more like the old days. Still not sure what happened to slow it down as I'm doing all the same things, but this helped speed up the bounce quite a bit. Someday I'll do an actual compare, but need to get this work out at the moment. I had previously quit all apps besides DP and didn't really notice a difference in bounce speed. The sudo purge command made way more of a difference in speed.

Thanks again Mike! And thanks all here for contributing.

[mikehalloran]

I first learned that trick in a very old post on MOTUNation years ago. Was it OS 10.4? Back in the days when you could max out a G4 with 1.5G RAM, it was a lifesaver for getting things done and I ran it often (my G5 had a whopping 4.5G!).

Were it not for this thread, I wouldn't have been curious to revisit the subject again. I was shocked to see how much RAM I was using and glad to see that sudo purge still worked—and surprised that it still made a difference. That my spouse came to me with a similar problem was pure coincidence but running those tests made me recognize the problem immediately.

The immediate upshot is that I ordered 32G RAM to upgrade the two 27" iMacs around here (my daughter's 2008 is maxed at 6G). Mine will be 32G while my wife's will be 20G when done. I found it at Crucial for $50 less than OWC and should have it by the end of the week.

So thanks to all. I have learned far more from these boards than I have contributed over the years.

[philbrown]

So thanks to all. I have learned far more from these boards than I have contributed over the years.

That's hard to believe, Mike!!
I feel that way x 10.
There are days when I'm pretty sure I'm the dumbest one 'contributing' here.

This is a good thread. Everyone should know the sudo purge trick.
I'm glad it's a short command and easy to remember.
Those long terminal commands scare me like I'm gonna toast the whole system with one letter out of place.