Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

slow after locking tracks

I have a 1 year old mini with 16 gozillion bytes of memory and 8 hyperventilating CPUs (2.3GHz i7). The only drive is the 1TB with SSD (256 MB?) It is 1/3 full.

Yosemite and GB and everything else are up to date as of yesterday. I executed a command to allow multithreading. (Doesn't seem to improve anything).


defaults write com.apple.garageband MD_AllowVirtualCores -bool yes


I have a teeny tiny project with 155 tracks. 8^O). The song is under 3 minutes.


The problem: Why does it takes forever to freeze all 155 tracks? As in 20 minutes. GB use almost no CPU or disk resources while freezing tracks? .


Today, I had the bright idea of slowing the tempo to see if something was off pitch. ALL THE SOUND DISAPPEARED. How do you spell HEART ATTACK??? I figured out that if I unlocked and locked the tracks, I got back the sound. HOWEVER! It took about 20 minutes to freeze all 155 of those tracks once they were relocked. I don't beleive my disk is fragmented; but, during the freeze, Activity Monitor says that the disk is writing about 8 MEGA bytes/sec. The project file is 3.5 GIGA bytes. The CPU was using about 4 or 5%. Is there extra dark matter in GB or the mini that slows it down? There is no obvious resource being used except the idle process.

Nothing else is going on. I don't use time machine or Apple TV or Apple Walk the Dog or Apple Mow the Lawn. My backup software, Backblaze, is set to slow mode. I purposely don't load up with extra apps. I pretty much use it only for GB and iMovie and I don't tinker around with it. All I can afford is GB. Is this project asking too much of GB? I haven't lost anything but time. Unless you count the dark matter.

Thank you

GarageBand 10

Posted on Apr 21, 2015 2:23 PM

Reply
Question marked as Best reply

Posted on Apr 22, 2015 7:37 AM

BillFromBrookhaven wrote:


The song is under 3 minutes.


Why does it takes forever to freeze all 155 tracks? As in 20 minutes.


just doing some quick maths in my head, that doesn't sound unreasonable; though please check my maths...


it's basically taking under 8 seconds to render out and write to disk each track, that sounds pretty fast to me. 8 secs * 155 tracks = 1,240 seconds (/ 60 ~~ 20.5 minutes)

4 replies
Question marked as Best reply

Apr 22, 2015 7:37 AM in response to BillFromBrookhaven

BillFromBrookhaven wrote:


The song is under 3 minutes.


Why does it takes forever to freeze all 155 tracks? As in 20 minutes.


just doing some quick maths in my head, that doesn't sound unreasonable; though please check my maths...


it's basically taking under 8 seconds to render out and write to disk each track, that sounds pretty fast to me. 8 secs * 155 tracks = 1,240 seconds (/ 60 ~~ 20.5 minutes)

Apr 22, 2015 7:33 AM in response to HangTime

WOW thanks for the fast reply. The math doesn't matter as much as the scale of what's going on. (A little musical humor there, sorry).


I think .aif's are uncompressed so it's just copying a few MB from memory to disk in 8 seconds. More bad humor says that an Apple II GS could write that to a floppy drive with a bad drive belt in that amount of time. 😉 To transpose the math into a different key (sorry, I can't help the musical humor), if the CPU is using 4% of it's time doing all this, it's not doing any rendering or anything else. It's waiting on something. If the disk is being written to at 8 MB/sec, it's waiting on something. I can't beleive that the seek time would slow the transfer rate of the disk this much. It's 1/3 full. Also, with 8 virtual CPUs, the way the activity monitor displays CPU usage, that is really 4% of 800%. I've made it go up to 800% in other ways. If one of the virtual CPUs could spend 100% of its time doing it's thing, and the disk transfer rate was, say, 100MB/sec then the track would be frozen 20 times faster (100% CPU / 5%CPU) = 20, which would be 1,240 seconds / 20. About a minute. Kind of makes you want to go hmmmmm.......


I can live with the slow freeze time because I hardly ever have to do this many track freezes at once. Just freezing 1 or 2 tracks takes just 5 seconds (Apple II GS speed).


I'm concerned that some kind of flaw in GB or OS X is slowing things down so much that my project is going to crash and burn and I will have wasted a whole lot of time. I can't find any articles about how to EASILY convert my GB projects into Logic Pro projects. Any help will be appreciated.

Apr 22, 2015 8:03 AM in response to BillFromBrookhaven

BillFromBrookhaven wrote:


I think .aif's are uncompressed so it's just copying a few MB from memory to disk in 8 seconds.


i don't know exactly how GB utilizes resources, but, it's slightly more involved than that.


even if the data is in memory (i would suspect it's often read from disc in real time), the 16-bit data is rendered out with any effects (reverb, compression, volume/pan curves, etc) and stored as a 32-bit file for maximum resolution.


BillFromBrookhaven wrote:


I can't find any articles about how to EASILY convert my GB projects into Logic Pro projects.


i imagine that's because it would be a very short article, something along the lines of:

  1. launch Logic Pro
  2. open GB project


the latest version of Logic will open the latest version of GB's projects (note, this is a one-way street; GB can not open a Logic-saved file)

---

best piece of advice: be sure you make incremental back-ups. that way if you do crash-and-burn at some point, you can always revert to your last saved file

slow after locking tracks

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.