Understanding RAM management when using Logic Pro

Has somebody written a post here about managing RAM in use with Logic? 

 

If not, would somebody who actually understands RAM Page ins & Page Outs and Swaps etc. explain this? It would be really helpful. Or someone 

I certainly don't . I would like to know when I'm at my RAM limit etc. Ideally BEFORE I'm at my RAM limit!

 

I would appreciate any links and tips!

Felix

AFAIK individual apps such as Logic do not page anything in or out, only OS X starts paging things from RAM to HD when the RAM is full. More info: https://support.apple.com/en-us/HT201538

 

As for Logic's management of RAM, Logic loads whole samples or only samples' attacks (depending on your sampler's DFD settings) for your sample libraries, it loads the code for your project file in RAM when you open the project file, it loads any Flexed audio file into RAM, all Apple Loops are in RAM, and the code for any plug-ins used by the current project is also loaded in RAM. Turning things on or off in a project does not affect its RAM usage. 

 

Hope that helps!

Thanks very much David,

That does help, I only just saw this update, sorry for the delay in replying!

 

Felix

You're welcome!

As a "card-carrying computer geek nerd," I can authoritatively add a bit of clarity to this particular discussion.  

 

Like every other operating system out there today, OS/X supports the concept of "virtual memory."  This means that each simultaneously-running program (including Logic [Pro], OS/X itself, and every other program that you are right-now using, whether you know it or not ...) operates in what it perceives to be "a private(!), so-called virtual, memory space."  (I guess you could say that it blissfully operates with rose-colored glasses firmly in place at all times, but this is absolutely intentional.)

 

It has no idea what OS/X is actually doing, nor does it care:  it only sees what it needs to see. ("Hey, this is the 21st Century! It's all about me!")    It does not perceive the existence of any other program besides itself.  "No one else is out there, competing for 'memory.'  (Or, indeed, 'competing with me' for anything at all.)  Everything that I see .. it all belongs to me." And, if need be, it might perceive that the "amount of memory" that it has at its disposal is greater(!) than the amount of RAM that your machine actually has.  

 

It is able to do this because of various "tricks of the hardware" that we need not discuss here unless you are curious enough to click on a hyperlink.    (But otherwise, "I digress.™")

 

Basically, though, "it's an illusion."  A very-clever and usually very-practical illusion that would have earned you a PhD "back in the day."  It's an illusion that works just fine for almost every program out there ... but not for a "real-time" program such as Logic Pro.

 

It's an illusion that is backed-up by the notion that, even though a program perceives that it has "such-and-so amount of 'memory' available to it," it will not actually reference all of that memory "all at once."  (Instead, it will right now reference a much smaller (albeit constantly-changing) subset, which was called its "working set" in the aforementioned – successful – PhD thesis.)  OS/X tries to make-available the memory that your program is actually using right now – its "working set" – available to it "right now," while quietly moving ("swapping" ...) the rest of it to disk.  Then, whenever the program actually references a piece of data that has been "swapped out," OS/X stops that program in its tracks until it has "retrieved the data back from disk, and adds it to the current working-set so that, at least for a while, it will be immediately-available again."

 

(Mumble, mumble ...)  "Demand paging."

 

So it goes.™

 

To your garden-variety web browser, e-mail client, or what-have-you, "hey, that's no big deal."  They're not "real-time."  They have no particular time-constraints.  They can very easily afford to wait a few milliseconds ... ("who cares?")

 

But ...

 

... for a "fundamentally real-time application, such as Logic Pro," that illusion crashes and burns.  Logic Pro, by its very nature and purpose, cannot afford to be "stopped in its tracks."  Ever!  ("If you ever get swapped-out, you're hosed.")

 

(Can you spell, "System Overload?"  Knew you could ... )

 

Logic Pro, by its very nature, must have "at all times, 'uncontested' access" to every physical resource that it requires, at the very instant that it requires it.  In other words, those resources "must actually, at all times, be real."  This means that you must not be running other "simultaneously active" programs, and that you must be running Logic on a machine that really does have the amount of RAM(!) that Logic demands "at that instant."

 

To a real-time application such as Logic, the physical constraints of your hardware are hard, and cannot be turned-away by any OS/X illusions that steal "precious time."  You must either add more hardware (specifically:  RAM ...), or you must adapt your project to live within your constraints, because "Logic Pro must not be delayed for any reason."

 

(koff ... koff ... pulls out his pocket-protector ... puts it away ...)

OS/X stops that program in its tracks until it has "retrieved the data back from disk

http://appleapple.top/wp-content/uploads/2015/06/6d9a7fbfed095272137d5220f9fee846.jpg

Turning things on or off in a project does not affect its RAM usage. 

Thanks for the insight David!

You say turning things on/off doesn't affect RAM usage, what can you do in a session to quickly free up RAM? As I thought turning tracks off would free up RAM, but if this isn't the case I will need new ways to free up some Memory when needed.

Only way to free up RAM is to unload resources from memory.  

 

So, that would be looking at things such as changing sample-based plugins to load direct from disk, instead of RAM if the option exists.  Bouncing down loops/flexed audio parts into audio files that match your project settings (Resolution/Bitrate etc.).  

 

Biggest release of RAM would be bouncing down plugins to audio that are requiring much RAM to operate (Big sample players for example), and of course, subsequently unloading them from the project and not just disabling them.

 

Price of RAM nowadays though, pffft, 'if' i hit a limit i would just increase the physical memory, so simple to do.

I might have a look into changing as many tracks as possible to load direct from disk, but might be tricky at the moment, as I run most of my stuff of a USB3.0 HDD. Do you know if you can set Kontakt to do this?

 

I try to avoid bouncing plugins down to audio, as I primarily work with Sample Libraries, and I'm always changing things as I go, so that just ends up taking tons of time.

 

I will be upgrading to 32GB of RAM in the near future, so shouldn't really be a problem, but I like to get the best out of my system.

How is it that you check how much memory Logic is using during a project? Is this something to view in Activity Monitor?so then you can compare what Logic is using vs how much RAM is physically present?

Open up Activity Monitor then go onto the Memory Tab, and if you look through the list of processes it will tell you how much memory is being used.

 

It's easiest if you sort the memory by how much is being used, as Logic is usually near the top.

 

You also have a bunch of information on how much memory is currently being used at the bottom.

what can you do in a session to quickly free up RAM?

That begs the question, what exactly in a Logic session is loaded into RAM?

• Sample attacks
  
• Entire samples (depending on DFD settings)
  
• Apple Loops
  
• Tracks that have Flex turned on
  
• Tracks that follow tempo

To unload those from RAM, bounce them in place to a proper audio track, and remove the original track.

Activity Monitor will show you the amount of RAM that any process is currently using, as well as the amount of RAM that OS/X thinks that the process "needs."

 

Since any reference to "memory" that is not "actually in RAM" will cause the entire shebang(!) to be frozen in its tracks, albeit perhaps only for a few milliseconds, this is the circumstance that you must avoid at all costs.

 

David, the answer to your question would necessarily be, "all of them."  Although Logic does split itself into "CPU-bound" and "input/output" threads, anything and everything that it needs in order to "make a sound" must be instantaneously available – in physical (not merely 'virtual') RAM.

 

If it isn't, the process is frozen in its tracks until the data can be retrieved from disk – and, "you're dead, Jim."

 

"Bouncing" is an excellent strategy because the preparation of the bounce audio-clip is not required to occur "in real time."  The computer is now free to take as much time as it may need in order to calculate the content of the bounce-track audio.  (Thereafter, takes an inconsequential amount of time to read the resulting audio file and play it back.)  It is quite obvious, from the ease with which Logic's designers made this particular feature available, that said designers anticipated that it would be used a lot.

 

If you can stand the idea of having to wait a short while for a track (or even the whole song or some segment thereof) to be rendered "off-line," overloads become a non-issue because the computer is no longer being demanded to work its Artful Magicks 'in real time."  The computer doesn't have to throw up its hands if it took "1.001 seconds" to render "1.000" seconds' worth of music ... which "in real time" would necessarily be fatal.  ("System Overload.")

 

If you can modify your workflow to accommodate or to circumvent the "real time" limitations of your particular system, "your particular system" can in fact go a long way.  "It just takes longer."  (And sometimes, "not much longer.")

Rob Douglas, have you tried "freeze" on tracks which you need to monitor whilst recording? I have just gone from 4GB to 16GB in a late 2012 mac mini today with absolutely no difference to the system overload nuisance. My hope is that new projects created with 16GB of RAM to play with will see fewer "System Overload" interferences later on. Like many sufferers, I had trouble-free operation initially - the system overload issue arose from thin air ... which is why so many Logic Pro X users cannot fix the issue, no matter what they change and no matter what they add. The idea behind "freeze" makes sense, but - like all purported fixes - it will not strike at the heart of the issue. The "nerd" appears to have opened up the heart of the issue - what users need is some surgical way of giving logic priority and preventing the mac from unnecessarily squirrelling data to places where it takes an age to get it back. Next, I will remove mail and other background programs to see if opening ONLY Logic from a cold start will deliver a return on the £99 investment in 16GB of RAM. As things stand, whatever it was that my late 2012 Mac Mini couldn't do with 4GB of RAM it still cannot do it with 16GB of RAM. To my mind this is an operating system issue which no amount of upgrading will defeat.

RobDouglas:what can you do in a session to quickly free up RAM?

That begs the question, what exactly in a Logic session is loaded into RAM?

• Sample attacks
  
• Entire samples (depending on DFD settings)
  
• Apple Loops
  
• Tracks that have Flex turned on
  
• Tracks that follow tempo

To unload those from RAM, bounce them in place to a proper audio track, and remove the original track.

David, what about freezing those tracks? Will I still get the same effect without bouncing these tracks to audio?

To unload those from RAM, bounce them in place to a proper audio track, and remove the original track.

David, what about freezing those tracks? Will I still get the same effect without bouncing these tracks to audio?

Yes, but you'll put a bit more stress on your HD (vs BIP) when freezing in 32 bits floating point.

David, what about freezing those tracks? Will I still get the same effect without bouncing these tracks to audio?

Yes, but you'll put a bit more stress on your HD (vs BIP) when freezing in 32 bits floating point.

Alright, thanks!

You're welcome!

what can you do in a session to quickly free up RAM?

That begs the question, what exactly in a Logic session is loaded into RAM?

• Sample attacks
  
• Entire samples (depending on DFD settings)
  
• Apple Loops
  
• Tracks that have Flex turned on
  
• Tracks that follow tempo

To unload those from RAM, bounce them in place to a proper audio track, and remove the original track.

 

The info above is very helpful, thanks for posting it! I was wondering how the RAM is affected when using multiple 'Project Alternatives' within a session. For example, if I'm not using a flexed track in the current 'Project Alternative' but it was used in a previous/earlier 'Project Alternative', does it affect the 'Project Alternative' that's active?

AFAIK project alternatives are loaded in RAM the same way projects are, so a flexed track in one alternative shouldn't affect another alternative.

Good to know! Thanks!

I use this while running Logic..https://itunes.apple.com/us/app/memory-cleaner/id426899026?mt=12

When BSD (like macOS) and Linux systems can’t get anything else in RAM, it “swaps” something from RAM to Disk. This obviously sucks for media.

 

There’s such a thing as “swap priority” in Linux which let’s you control what gets swapped out, no idea if MacOS has it.

A "project alternative" that isn't being referenced might be "in memory," but it's likely to be "stolen" by the operating system as a "LRU = Least Recently Used" page. It gets swapped out until – and, unless – you actively reference it again.

 

What you r-e-a-l-l-y want to make sure of is that, "virtual memory swapping" (that is, of "recently used" or "actively needed" material), never happens.

 

"Chips are Cheap™" nowadays. Splurge. You may have already noticed that nothing "makes your computer run faster" than adding more RAM to it.

"Chips are Cheap™" nowadays. Splurge. You may have already noticed that nothing "makes your computer run faster" than adding more RAM to it.

...That's if you can upgrade the RAM of course, as cheap as chips are, some like to smother them in solder.