Vienna Symphonic Library Forum
Forum Statistics

185,278 users have contributed to 42,390 threads and 255,479 posts.

In the past 24 hours, we have 2 new thread(s), 21 new post(s) and 52 new user(s).

  • Intel Mac Pro RAM issues?

    I'm hearing rumblings about the VI's having problems using more than two gigs of RAM. I was planning to get a huge MacPro with tons of RAM and run multiple copies (as opposed to instances of the plugin inside a host) of the VI's, but if this isn't working, then maybe I shouldn't waste the Mac on it. Any thoughts? Anyone else doing this?

    Also, I've been waiting for a stress test done on an Intel Mac. Any takers?

  • kerblooie:

    Your user name sounds like some of my previous experiences!!

    As for RAM, I'd read somewhere on macfixit.com that there were some questions about more than 3GB with RAM leaks or data overlapping. It was inconclusive and I've been waiting for more info on it.

    2GB sounds low, actually, and I know users who are doing well with more than 3GB RAM. Honestly, it's all a bit confusing-- and expensive to be so confusing.

    As for tons of RAM, keep in mind that no single app will access more than 4GB and probably closer to 3-3.5GB. That just means that beyond your DAW and all VIs or fx loaded into it above 3-3.5GB, any extra RAM would be best served by running standalone instances outside of the DAW to access another 3-3.5GB.

    So, if the machine you get takes 16GB of RAM, remember that only 25% of that at the most will be dedicated to your DAW and all that is run inside of it. Beyond that, consider a secondary VI host such as Plogue Bidule to load up with additional instances of plugins... and buy RAM accordingly and sensibly.

  • last edited
    last edited

    @JWL said:


    2GB sounds low, actually, and I know users who are doing well with more than 3GB RAM. Honestly, it's all a bit confusing-- and expensive to be so confusing.



    Thanks for the input, JWL. Truer words were never spoken.

    What I've been wondering is this: If I create a standalone VI, does it launch another VI server app that then has access to th additional memory?

    Also, if a patch is loaded in one VI instanciated as a plugin inside a host (say, Logic) and I then launch a standalone version (or one inside Bidule, for example), are they aware of what samples are already loaded into memory, or would they be addressing independent sample pools? I ask because it seems that if they were aware of each other, then might one be able to get more samples playing on one machine from one host simply by launching standalones with as many patches as one might use in a sequence and then launching the sequencer, which would then have access to all of those samples by launching VI's as plugins addressing the same patches? Rather than connecting them via a Rewire host or Soundflower...

    Admittedly I know nothing of programming, but wouldn't a cool workaround to the 32-bit OS limitations be to have VI's able to read from any part of RAM, not just RAM the standalone app or host app has allocated?

    It's probably some mad dream. I haven't finished my French Market coffee yet.

  • last edited
    last edited
    Hey there,

    You can indeed run multiple stand-alone instances on one computer. There's a lenghty topic about that in the forum.

    When testing, I was able to go up to 7GB of memory on 4 stand-alones (Total : 3 + 1.5 + 1.5 + 1 = 7 GB of samples.) I didn't test it enough to say if it is stable or not, but it appeared so.

    The problem is that you can't choose an audio channel out of the stand-alone: you can only choose the audio interface and then go out channels 1-2.

    Jerome

  • last edited
    last edited

    @kerblooie said:

    Also, if a patch is loaded in one VI instanciated as a plugin inside a host (say, Logic) and I then launch a standalone version (or one inside Bidule, for example), are they aware of what samples are already loaded into memory, or would they be addressing independent sample pools? I ask because it seems that if they were aware of each other, then might one be able to get more samples playing on one machine from one host simply by launching standalones with as many patches as one might use in a sequence and then launching the sequencer, which would then have access to all of those samples by launching VI's as plugins addressing the same patches? Rather than connecting them via a Rewire host or Soundflower...


    AFAIK, when one loads an instance outside of the DAW using the same patches, a different copy of the same samples will be loaded. The only thing that connects them is the audio as Jerome mentions. This, I think, is the nature of "standalone" by definition. (Someone correct me if I'm wrong.)

    But this is where careful planning comes into play. If you are running violins inside your host, then keep the violin samples there. Save other CPU and virtual memory resources from running other instrument groups, like cellos or some combo of winds, etc. You can avoid doubling up on samples this way-- and you can eventually "dump unused samples" to save additional resources as well.

    I've not experienced any hassles with getting standalone instances or instances loaded into a second host to chime into my main host, fwiw.

  • Hey JWL,

    I'm not sure I understand why you are loading VI instances in two different hosts?

    Jerome

  • last edited
    last edited

    @Jerome said:

    Hey JWL,

    I'm not sure I understand why you are loading VI instances in two different hosts?

    Jerome


    I've got 8G RAM, so I can only get "so many" instances running smoothly inside my DAW. Using standalone or Bidule or some other low profile host, I can load more instances outside of my DAW. Why that works I dunno, but it comes in handy.

    My DAW is max'd with the instances I'm using and how they are loaded up with custom matrices. If I add another instance inside my main DAW, the performance suffers no matter how I change my buffers or other settings. I can squeeze in other instances via standalone or a second host (not many, mind you).

    I know, I know. It's time for an Intel...

  • Oh, ok, so it's more a CPU issue than a RAM issue...

    That's interesting... I did notice that Plogue's DSP starts going crazy after loading 10-15 instances on a dual-G5; I will make some tests to see if by running Rax along that and loading 5 instances into RAX instead of Plogue, the CPU holds better!

    Jerome

  • last edited
    last edited

    @Jerome said:

    Oh, ok, so it's more a CPU issue than a RAM issue...

    That's interesting... I did notice that Plogue's DSP starts going crazy after loading 10-15 instances on a dual-G5; I will make some tests to see if by running Rax along that and loading 5 instances into RAX instead of Plogue, the CPU holds better!

    Jerome


    Yeah, it's more of a stability issue. Nothing is crashing, but after so many instances are loaded into one place the pops and clicks start.