Vienna Symphonic Library Forum
Forum Statistics

194,269 users have contributed to 42,914 threads and 257,946 posts.

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

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries
  4. Alternate way around the 2.5 GB RAM limit?

  • Alternate way around the 2.5 GB RAM limit?

    P
    P
    There have been several threads dedicated to how to use Vienna Instruments simultaneously as 1) plug-ins within a sequencer and 2) separately as a standalone (or multiple standalones), to get around the 2.5 GB RAM limit per process. So I had another idea. (Forgive me if this is an old, discarded idea! [:)])

    On a slave machine, could you use multiple plug-in HOST programs simultaneously (as opposed to just running multiple stand-alones), with each getting its separate quota of RAM? E.g., let's say you ran Plogue Bidule, RAX, Brainspawn and V-Stack at the same time on a slaved Mac Pro with 16GB of RAM. Let's also say that said Mac Pro has an audio card with 8 outs. Wouldn't this give you the ability to:

    1) Access up to 10 or 12 GB of RAM
    2) Host many instances of VI, distributed across the four programs
    3) Route them flexibly to any of the 8 outs?

    OR... would there be a problem with the different host programs addressing the audio card's outputs simultaneously?

    Has this been discussed? Tried? Might someone try this?

    Thanks,
    Peter
  • M
    M
    Good meeting you the other day at Skyline. I like the idea.... That would require you to be able to run multiple VSL servers simultaneously - does anyone know if this is possible? Tomorrow, I will see if i can do it on our Mac Pro...

    Cheers,

    Shane

    "Dr. Koss"
  • N
    N
    Whether it's a host or a slave doesn't matter - the VSL Server program that contains the plug-in can only access its memory allotment of (2.5GB or closer to 3). In other words, each host shares the same 2.5/3GB allotted to VSL plug-ins on a single machine.

    You get one allotment for plug-ins and one for each stand-alone.

    I thought about this too, but unfortunately it doesn't work.
  • P
    P
    Ah - so the Vi plug-ins use RAM allocated to the VSL server, not to the host program. Makes sense. Sadly.

    But I wonder how far you could take the multiple Standalone idea on a fully tricked out Mac Pro (to supplement Bidule plug-in instances) -- 10 of 'em? 20? (Assuming you're not loading that many articulations in each.) Also obviously a pretty big pain to have to start them all up each day.

    Shane - thanks for organizing Paul S's NYC Vi demo -- 'twas great, and fun to meet everyone. Hey, if you try this trick anyway, what the heck, let us know what happens!

    PL
  • N
    N
    It's a pain to start them all up - although there's probably a way to record a macro to do that - but after that they're all started and you don't have to reload them every time you start a new cue. And of course you're getting more mileage out of a single Mac than anyone has got out of any machine before.

    What I'm mildly curious about is if you can keep going on a Mac Pro with 16GB installed, or if you just run out of CPU before that point. I'm not sure you'd want to load much more than that on a single machine anyway, just because it would take so long. And of course the RAM is still hellishly expensive.

    Anyway, I find running stand-alone programs outside the host to be a perfectly reasonable solution to one of the biggest problems with sampling. Three years ago it was a big deal to be able to get over 1GB loaded in a single Giga machine.

    The other thing you have to look at is the quantity of samples you're loading into that RAM we're accessing, mainly how small the buffers are. VSL is very good about that.
  • J
    J
    last edited
    last edited

    @Nick Batzdorf said:

    It's a pain to start them all up - although there's probably a way to record a macro to do that - but after that they're all started and you don't have to reload them every time you start a new cue. And of course you're getting more mileage out of a single Mac than anyone has got out of any machine before.


    Not to go OT-- but you can at least set your Startup Items in System Prefs in OSX. If your host can be set to autoload your project, all you need to do is log out and log back in. Upon boot, everything will load without thinking about it

    http://docs.info.apple.com/article.html?artnum=106146

    A macro would offer greater flexibility. I was able to do this when I used the driver for a programmable Kensington mouse, but I've not tried to macro-start in OSX.
  • J
    J
    The whole idea of setups and templates is actually a major issue, I'm finding. Yesterday I spent almost all day devising a new setup for working between Live and Logic, with VIs (and EXS) hosted in Logic, but using the midi "clip" functionality of Live (which I actually find really handy for certain types of work).

    On the whole subject of macros you could, of course, go absolutely mad with shell scripts in OS X, or with applescript... I've even considered having different user accounts for different basic types of project. The issue seems to be that, with so much variety in the library, you can wind up with either a highly flexible setup which is almost impossible to navigate and manage, or a setup that's simple and intuitive to get around, but lacking flexibility. It's tough. The VI interface itself, of course, makes huge advances in this department. But on OS X at least, it's a bit of a pain getting to, and keeping track of, the various instances. This is why I suggested the idea of a VI "rack" a while ago, but nobody really took to the idea. (Or, of course, a VSL scoring program, which could also solve this problem in a blink!) Anyway, until it's possible to just get *everything* up and running at once, with articulations mapped to a common set of controllers (which I'm sure some "farm" owners have managed) I think I'll continue to have this problem. It's pretty much unavoidable with such a huge library.

    J.
  • P
    P
    Ah, templates. Don't you find that no matter how elaborate and careful you are with a template, almost every cue demands something you didn't think of? ("A sitar[or harmonic string glisses/growl trumpet/water bubble fx] would be nice...")

    Re working with a stable of VI standalones -- obviously it would be awesome if there was some way of making a "rack" of VI standalones, but I imagine that's just as hard software-wise (or it's the same problem) as creating a "2nd VSL server" to give you more plug-in RAM. Love the tip about including VI standalones as startup items, but as far as I know you can't have a standalone load a "default preset" on startup (am I right?). SO....

    As a stop-gap, wonder if the VI programmers would consider adding that functionality (default preset) to each standalone (along with the ability to choose which of your audio card's outputs each standalone addresses)? That way, you start up your slave machine, make coffee, and it's ready to go. Unless, of course, you'd have multiple standalones that share audio files trying to simultaneously load the same files into RAM.

    Make any sense? Or just drivel?
  • N
    N
    JWL: I don't think there's a way to get stand-alone Vienna Instruments players to load the programs you want in them automatically. The reason is that the second and subsequenct instances have to be renamed, and presets only know they belong to the main player.

    But I don't think this is a huge deal, because you're unlikely to be running more than, say, five stand-alone players outside your DAW. And if you're running Kontakt-family players outside the DAW, they have up to 64 slots and Multis will load right in.

    (I don't only use VSL, of course, so I'm looking at a bigger picture.)
  • J
    J
    last edited
    last edited

    @Nick Batzdorf said:

    JWL: I don't think there's a way to get stand-alone Vienna Instruments players to load the programs you want in them automatically. The reason is that the second and subsequenct instances have to be renamed, and presets only know they belong to the main player.

    But I don't think this is a huge deal, because you're unlikely to be running more than, say, five stand-alone players outside your DAW. And if you're running Kontakt-family players outside the DAW, they have up to 64 slots and Multis will load right in.

    (I don't only use VSL, of course, so I'm looking at a bigger picture.)


    Very good, Nick. I was aware of some caveats, but as these templates and setups become more complex in the name of simplicty-- [:D] the general shortcuts and generic automated conveniences quickly reach a point of diminishing returns-- multiple standalone VI Consoles being case and point as you've cited.

    There are indeed many things I love about OSX and an increasing number of things that bother me this late in its incarnation. The ability to select apps to autostart on boot is nice, but having lost the ability from OS9 with Keyboard and Mouse to assign an app-start to a user defined macro was for a me a big loss (I know, Quickeys does much of this, but what was part of Apple's last-gen OS is now available as a third-party utility for a price).

    The other mixed blessing is the ability to disable Virtual Memory as in OS9. While faster CPUs have taken some of the burden off the process, hard drive speeds really haven't changed much, with the exception of 10k and 15k drives being more common now. OSX's virtual memory is clever in the way it takes care of business automatically, but I should wonder if VM for VI trades some quality for the sake of quantity.
  • N
    N
    Whoever it was at CE Software who snarled at me to buy the program again when I called for help with a missing auth code a few years ago sealed that company's fate. It doesn't help that QuicKeys was absolute crap on OS X at the time (although it was essential on OS 9).

    I now use iKey from Scriptsoftware.com for launching programs and Funkeys X for a few other things (such as switching to the Finder and hiding all programs).

    But I have to say that for me, having to load a few stand-alone programs is not close to the point of diminishing returns. It takes no more time than starting up and loading two more machines, and it's a whole lot less expensive.
  • P
    P
    Nick -- re your comment about why you can't create default presets multiple VI Standalones:

    <<presets only know they belong to the main player. >>

    Does that mean that if you open additional (renamed) instances of the VI Standalone, the presets won't be visible in the VI browser? Or am I misunderstanding what you said?

    Thanks,
    Peter
  • N
    N
    No no, you can certainly open them. I just mean that if you double-click on the presets themselves they won't know to open "Copy of copy of Vienna Instruments Standalone" - they'll try to open Vienna Instruments Standalone.

    The whole scheme works very well, with the two limitations that you have to load each one by hand and that you have to resort to trickery to get more than two outputs out of the Vienna Instruments player.
  • P
    P
    Gotcha -- so you can't set the PRESETS as start-up items. I wonder if you could set all the differently-named VI Standalone applications as start-ups. Then if my "default preset" idea were implemented by VSL, the standalones would load their own presets. Unless, of course, they all share the same preferences file.

    Anyway, as you say, not such a big deal to open them individually. However, wondered if you could advise re the tricks you use to route VI Standalones to outputs other than the default pair. Must one use Logic? (I don't.) Or could this be done on a slave machine? If the Standalone could be a Rewire slave it could be done through Bidule (which can be a Rewire master).

    PL
  • N
    N
    Sure you can put make those programs start up automatically. You could even name each copy of the V.I. player so you know what gets loaded, e.g. "V.I. Player vlas blablaba."

    Here's the thread with all the info:

    http://community.vsl.co.at/viewtopic.php?t=9801&highlight=soundflower