Vienna Symphonic Library Forum
Forum Statistics

182,716 users have contributed to 42,254 threads and 254,893 posts.

In the past 24 hours, we have 1 new thread(s), 5 new post(s) and 41 new user(s).

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries
  4. Memory Management on the Mac Pro

  • Memory Management on the Mac Pro

    C
    C

    There seems to be a lot of intelligent and tech savvy individuals on this forum and was wondering if anyone has experienced issues with memory management on the Mac Pro?  Through my observations and working with my system 16+ hour per day over the past 3 years, I'm beginning to see a pattern developing which may also be a contributing factor to some of the issues I've seen other users identify on this site.  A couple of scenarios:

    1.  When working with Ensemble-Pro:

    I've been watching the memory meter in the activity monitor while loading samples and have seen the following results.  I will be in the process of creating some custom matrix using a single instrument in VE-PRO for example.  Once created, I will load different patches in the same matrix and provide a new name representing the articulation.  Sometimes I'll get on a roll and create 15 - 20 of these custom matrixes at one sitting -- mixing and matching like instrument patches from Chamber, Orchestra and Appassionata for example.  What I've noticed that even though I'm replacing the previous patches, the memory continues to rise to the point where eventually, the system crashes.  If I would exit everything and reloaded where I left off, the memory counter resets.

    2.  When working in Logic using either VI or some other manufacture instrument (and not just one company), if I set up a channel strip and save, dump the channel strip and load a different instrument channel strip -- over time, the memory continues to climb even though the samples should be replaced and the memory stay somewhat constant.  I've notice the same thing happening when using Cubase or Pro Tools.

    3.  In the case of a large instrument such as QL Pianos, after loading a strip, then dumping and reloading, the latency is noticeably increased to where I have to exit Logic and reloaded to rectify the problem.  The same is in Cubase if I attempt to freeze a track and dump the memory.  It happens with VI over long periods but more noticeable when using something large like QL Pianos. 

    All said, this seems to me to be a memory management issues within the OS on the Mac.

    Has anyone else seen this or is this possibly a known issue in the Mac Pro community that I am just not aware of?
  • J
    J

    Chuck,

    DId you ever get an answer for these questions? What's your workaround?

    Thx

    J
  • C
    C
    last edited
    last edited

    @jeremyroberts said:

    Chuck,

    DId you ever get an answer for these questions? What's your workaround?

    Thx

    J

    No Jeremy,

    No answer... My workaround (which is usually required more when developing a new template, it to exit all programs and reboot the system in order to get a fresh memory start....
  • J
    J

    Chuck,

    Thanks for the reply.

    This is pretty lame, is you ask me...

    Forcing a restart to release ram used within an application sounds like the VSL engineers haven't yet mastered OSX coding. I am no coder, but as a 30+ year veteran of computers, I know that some applications can do this. If so, why not VSL in VEPro? The "memory purge" feature is already there in VE Pro with respect to "learn/optimize/RELEASE" function. The RELEASE function should simply purge all deleted patches. It really should be done automagically by the software.

    Why the designers did not make this a priority is beyond me. Expecting me to restart my machine is not a streamlined workflow. Before VI Pro, they need to fine-tune the current featureset. My $.02 (which is worth much more today than last year).

    J
  • R
    R

    Chuck,

    I can confirm  your second observation. I also use the MacPro, but the memory behavior is not related to the hardware and more to the way how OSX handles the RAM. 

    Here is a link to Apple's developer's site that explains "Memory Management in Mac OS X". Trust me, I don't understand a lot of that stuff either because it is a little hardcore but you might get somewhat of an idea what is going on, plus some useful terminology. :

    http://developer.apple.com/mac/library/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html#//apple_ref/doc/uid/20001880-BCICIHAB

    The phenomena you are looking for is the "Inactive Memory" or "Inactive List". This is a great concept but it bites you in the but with the new 64bit apps. Every time you close an app that used up memory or in our case we load/unload some plugin+samples, OSX doesn't release the memory completely. It tries to help and keep some data in RAM just in case you reload the app. In that case OSX knows it has that data still in RAM and zzing, the app is up and running in no time.

    This was not a big problem with 32bit Logic because it had its own 4GB memory ceiling. But now with the 64bit version you keep on loading samples and they stay in RAM, marked as "inactive". You see in Activity Monitor that your free memory shrinks more and more and after a while you see that your 16GB or more of RAM is used up even if you didn't kept the last 10 presets, you overwrote them. However, OSX kept them in RAM for your convenience.

    This is basically not that bad because if OSX needs more RAM, it releases some of the inactive RAM for the new one. However, I noticed that you are entering another danger zone - SWAP SPACE. This is the arch enemy of all audio apps. It means that OSX sees that the physical RM is all used up and it starts to outsource some data from fast RAM to the slow Hard Drive. The result, possible clicking sounds. This is the main reason to always have an eye on the Activity Monitor, or have Menu Meter running, to make sure that "page outs" always reads 0.

    Now this is a perfect example where I run against  a wall regarding VSL's infamous authentication procedure. I try to explain people that a "perfect world" situation has nothing to do with our real life 16h/day real world situation using Logic, Vienna AND other plugins. I hear that people can live with a daily 3-5 minutes authentication process. But this is one example where you might want to restart your computer, tabula rasa for the RAM. Now the 3-5 minutes can add up and you can start to calculate the time=$$$ on lost productivity.

    More on that related topic under:

    http://community.vsl.co.at/forums/t/25361.aspx

    Maybe there is a little UNIX app that flushes the inactive RAM, I haven't seen any, but that would definitely help
  • C
    C

    Agree with everything you've said Edger...  What you explained is what I have understood to be the issue.  When I was leading an IT organization in the auto manufacturing world, we had a similar issue with our unix boxes and a custom plant floor application.  In this case it was a client sever configuration that used HP X-Terms as smart terminals and a bank of HP 735's as the servers.  A great architecture because as the needs grew (system expansion) all we had to do is buy another 735 servers and redistribute the workload.  

    What we found was that every time an X-Term terminal would sign on, it would use some memory space on the server farm.  Everything was ok as long as one didn't turn off the terminal.  Turn it of and return it back on, and another memory block would be used up.  Multiply that by 350 X-Terms and it didn't take long before we were up against the wall in memory.

    I had our developers write an application that would periodiacally go out and clean (free up) the memory space.  Again, it was a function of the OS.  Other examples I've experienced is application that reserve array space that doesn't get freed up if the programmer doesn't account for it.

    I agree with you that an app to clear memory at the OS level would be a great thing so we wouldn't have to reboot and go through the authorization process........