Logic Pro 9 Logic 9 Eating my CPU like the Cookie Monster

ben37

New Member
Hi there, first post. I'm a long time musician, fairly new to electronic music production.
I'm getting into my first 20-30+ track projects, with multiple instances of Kontact instruments, Soundtoys plugins, Sylenth1, Razor, etc.

I find that even one instance of NI Razor can cause CPU overload immediately. Wow.

Anyway, I did a little research and some folks said I should switch to 64 bit, and I did that but it didn't make much of a difference. Activity Monitor still shows Logic using 120% (huh?!) of my Memory.

Also, now most of my VST plugins are 32 bit, which still works in 64 bit Logic of course, but the 32 bit bridge server keeps crashing every time I try to play my track.

If I close any open apps, restart the computer, and open Logic, I can play the track for a little while before I start seeing the System Overload error message. But it always happens eventually. Sometimes the track won't even play at all, and I spend considerable amounts of time staring at the colorful twirly thing which all mac users love so much. :angryfire:

Now don't kill me when I tell you I only have 4 gb Ram on my mac. I should have more right?? I hope the answer is that simple! Thanks for any help or ideas! :thmbup:

-Ben

Logic 9.1.5 64 bit, Late 2008 MacBook pro 2.66 ghz 4 g ram. Running Lion.
 
Well, I can tell you a few things:

1) Logic only uses a single CPU to "perform" any virtual instrument sound. If you use a plug-in that can completely eat your cpu (think u-he ACE, Sculpture, any convolution reverb with a long decay) your pooched right from the get go.

2) Ram helps, but is a non factor in performance. It comes into play when you are using allot of sample based stuff, like BFD drums, Omnisphere (a sound can sometimes contain 8 parts that use huge samples to make).

3) Your drive is most likely a 5400 rpm drive. I'd suggest upgrading it to a never drive that is 7200 rmp with a big cache (64 meg helps). Or a SSD if you can afford it though they are still a little too costly for me.

4) In this case, 32 bit might be a better option: no server to deal with, and if you need to go 64 Logic will say you need to save the file because memory is low, just save, change to 64 bit, and carry on.

5) The 32 bit server thing can crash all it wants (and often does ;-). It is mainly used to have the graphics of the plug-in to be shown. It doesn't hurt anything, at least not in my experience.

6) Freezing tracks is your best friend if you are using lots of VI's that are DSP based (Razor, ES2, any plug-in that causes cpu overloads). create your part, freeze your track, then go on to the next part.

7) Always restart your computer before you start a session. it cleans up the system memory, and can often turn off background things from other apps that could be a drain on your CPU.

8) a dual core 2.66 system is a pretty DSP challenged system to begin with, especially is you are using more DSP based stuff.

9) Make a blank track with an empty folder in it. Select it when you are just listening, so you have no tracks in live mode taking up some of your CPU power.

These are a few things that can help anyone, not just a person with a lower powered CPU.
 
Upvote 0
5) The 32 bit server thing can crash all it wants (and often does ;-). It is mainly used to have the graphics of the plug-in to be shown. It doesn't hurt anything, at least not in my experience.

Actually the bridge is a tiny layer between a 64-bit Logic and 32-bit AudioUnits. Right now I would expect that almost all crashes of the bridge are actually an AudioUnit having a problem. This is not only the graphics, but also the audio processing - the whole AudioUnit is 32-bit, so this includes audio processing.
 
Upvote 0
5) The 32 bit server thing can crash all it wants (and often does ;-). It is mainly used to have the graphics of the plug-in to be shown. It doesn't hurt anything, at least not in my experience.

Actually the bridge is a tiny layer between a 64-bit Logic and 32-bit AudioUnits. Right now I would expect that almost all crashes of the bridge are actually an AudioUnit having a problem. This is not only the graphics, but also the audio processing - the whole AudioUnit is 32-bit, so this includes audio processing.

Well maybe for you, but in my experience it doesn't seem to do much to harm anything. If I'm running Addictive Drums, and the 32 bit server crashes, I still hear my drum sounds (as a multichannel plug-in) just fine.
Since I'm not a programmer, all I can do is see how it works, then make a guess on what something does by experience. Like I said, in my experience, the 32 bit server crashing doesn't do anything. I just reboot the thing, and off I go. If I don't reboot the server, I still hear my plug-in just fine.

Who knows, maybe I'm just lucky. Since this thread is being read by more than a couple of people, can anyone else comment on their experiences with what happens when the 32 bit AU server app crashes on them? Maybe we can get to the bottom of this mystery.

I'd LOVE if someone from Apple/Emagic could comment and give us a real answer about how this thing works, since the documentation is about as thin as a piece of hair ;-))
 
Upvote 0
6) Freezing tracks is your best friend if you are using lots of VI's that are DSP based (Razor, ES2, any plug-in that causes cpu overloads). create your part, freeze your track, then go on to the next part.

9) Make a blank track with an empty folder in it. Select it when you are just listening, so you have no tracks in live mode taking up some of your CPU power.

Thank you for the great response George! Can you please clarify the above? I'm not sure what you mean by freezing tracks, or how to make a blank track with an empty folder for listening.

However, if I implement those ideas into my workflow, perhaps switch back to 32 bit, upgrade to 8 GB Ram (I'd love to run bigger sample stuff like omnisphere), and upgrade to a faster rpm drive with a bigger cache, will I be able to start completing projects?

Or should I work harder for a few months and just buy a new fast iMac!? (not my preference, ha).

Thanks again.
 
Upvote 0
Hey ben37,

Ref georgelegeriii's point 6) From the Logic Manual:-

Understanding the Freeze Function

Internally, Freeze performs individual offline bounce processes for each frozen track. All plug-ins of a track (including software instrument plug-ins, if applicable, along with all related automation data) are rendered into a freeze file.

Hope that helps 🙂
 
Upvote 0
I missed off this:-

As long as a track is frozen-following the freeze process-the freeze file will play back in place of the original track (and its CPU-hungry plug-ins). The original track and plug-ins are temporarily deactivated, and use no CPU resources.

:S
 
Upvote 0
Back
Top