Vienna Symphonic Library Forum
Forum Statistics

182,288 users have contributed to 42,217 threads and 254,748 posts.

In the past 24 hours, we have 3 new thread(s), 19 new post(s) and 44 new user(s).

  • Vienna Ensemble RAM usage question

    After I stopped stammering incoherently with excitement, I focused on the following phrase:

    <<Separated server solution that doesn’t address RAM used either by your host sequencer or by Vienna Instruments plug-ins running alongside the sequencer and Vienna Ensemble.>>

    Here's what I think this means - do I have this right?  Note I'm assuming that for the time being we're still in 32-bit land:

    1. Plug-ins that are instantiated in your host sequencer continue to address their own RAM (i.e., the VSL server), and that's still separate from the host sequencer's application RAM allotment.

    2. Vienna Ensemble will have it's own separate RAM allotment (so if you've maxed out the VSL Server that covers your sequencer's plug-in RAM at, say, 3 GB, you can have access to another 3 GB or so through Vienna Ensemble).

    3. Vienna Standalone instances will continue to address RAM separate from anything listed in 1 and 2 above.

    Am I right? Can this be true?

    Peter 


  • Hi Peter,

    Yes, this is exactly how it is. By using the the AU/VST Plug-in version alongside with the Vienna Ensemble on a Mac you will be able to address about 2.9 GB  RAM with the vsl server AND additionally about the same RAM with Vienna Ensemble. This is possible under a 32 bit OS.

    best
    chrisK


  • Quick question, is/will the Ensemble play nicely with Leopard, and if so 32 or 64 address space? Many Thanks Dave Hage

  • Mind you, it also says "Prepared for 64-bit Macs and PCs". So, I'm assuming they're being ultra-conscientious and making a system that will be able to access the maximum possible RAM *regardless* of whether you're running 64-bit or not. Since we still don't have a genuine 64-bit Mac OS, and most people aren't running XP x64 or Vista 64 (with appropriate drivers, hosts, etc.), they've made something that will not only work "in the meantime", but will also address the maximum possible RAM *now*. Nice decision, on their part, I think. --- J.

  • It appears that VE (standalone and plug) as well as VI use approximately twice as much RAM as it should, as indicated in the Activity Monitor. any suggestions would be very helpful. Thanks VE (build 2869) VI 1.14 Mac OS 10.4.11 MacPro 2.66 Dual-Core 8 GB RAM

  • ddunn, what makes you assume VE or VI is using twice the RAM as it should? each loaded stereo sample needs 64 KB memory for the preload buffer, the application (or plugin) as such also needs some MB of course ...

    please note that RAM usage in the activity monitor will show a certain amount of used RAM even if you unload some instruments due to memory management - loading the same instrument again needs only to restore the pointers then which speeds up the process, this memory can be used by other instruments when needed though ...

     

    dfhage, VE and VI run actually smoother on leopard than on 10.4 and both can use all available memory - not within a single instance though ...

    whereas the memory management as such is 64 bit the VI and VE is not currently. this means every process (of such an instance) is limited to ~ 3.2 GB memory usage. this is subject to change.

    christian

     


    and remember: only a CRAY can run an endless loop in just three seconds.
  • Regarding "the application (or plugin) as such also needs some MB of course ..": I was wondering whether people have seriously looked into the amount of RAM each extra VI instance adds to what Vienna Ensemble consumes. Specifically, I clearly remember that an instance in VE, according to the promo videos comes in instantaneously "because it is already there", but if I monitor my resources whilst adding an empty VI instance in VE, it actually loads another 20 MB. I know this does not sound like a giant lot to most of us here, but the fact remains that most patches require less than that (as long as they're not legato), and far less even if the RAM has been 'rinsed', so to speak. So, usually, I use so many VI instances that my RAM (a somewhat meagre 2 GB) mostly seems to have to cope with the VI instances, not the samples themselves.

    Anyway, from a programmer's point of view, it seems to me that quite a bit of the 20 mb (x 40 instances is about 800 MB) is redundant information: the GUI of the instances is always the same, that sort of thing. Can we expect that a later version of VE might implement a way to 'share' (like the memory for samples is shared, as you say above) some of the memory that is now common amongst instances, yet treated independently?

    Second question: is there anything that can be done about Windows garbage-collecting memory that is used by the VE? It's not new for softsamplers, I remember HALion in particular being a pain after leaving the computer for dinner break... The idea is that after some time, memory that is not used gets, well, I don't know what, but I presume it is being garbage-collected or something, because it is certainly not instantly accessible anymore. I try this: load everything, vienna instances tell me there's 150 mb left... wait an hour, play: stuttering and crackling like a crackw - er, nevermind. Memory left: suddenly there's 400 mb! So, what I do now is just looping my song, so everything is still okay after dinner, no dips, and that works, except that I can't really do that with live performances. The question then: am I guessing correctly and is it garbage-collection (or is that too .net?), but more importantly, can something be done about it?

    Thanks for everything, I remain a great vsl enthousiast!

    Cheers, 

    Michiel

    Note: I use VE 2.02 and VI 1.14 on Windows Vista and XP SP2, Xeon AMD 3800+, 2G RAM, usually as a plugin in Cubase Studio 4.1.1 via an MAudio Fasttrack pro or Behringer BCA2000.


  • michiel, besides we are turning over to windows now, as often answers are *yes and no* ...

     

    Vienna Ensemble starts with about 50 MB RAM usage ... each inserted VI instance will add some amount ... of course a lot of information seems to be redundant, but in fact you would need the *space* to save a complete set of settings (you know the math ... 12  x 12 x 12 x all parameters) ... so 20 MB seems not too much in my view ... you might also notice RAM usage *toggles* a little bit depending on the subset of the GUI you are currently displaying ...

     

    the garbage collecting .... well, this term seems not to fit for me in this case ... collecting garbage means basically to remove unused instances, processes, free unused memory, ect .... with sample streaming the processes and memory is not *unused* but just *currently not used* ... in both operating systems the memory requested for the sample headers is *marked as not to be paged out* ... whereas winXP does fulfill this requirement, apple has confirmed OS X does not and i'm currently not sure if VISTA really does (sometimes im under the impression it does not 100%) ... in any case i don't consider VISTA's prefetch technology as ideal solution for sampling machines.

     

    however there is a lot more stuff which can be paged out and might affect the overall performance of a machine after pausing for a longer time ... wherever possible i therefore set the page file to *don't use* ... unfortunately some applications don't like that at all, so i'd try to set the lowest value possible to avoid windows trying to be more clever than the user ;-)

     

    we must not forget ourdays systems are much more *multi purpose* operating systems than earlier ones and in my opinion less adjusted for realtime applications than ever before ... we need to handle that ...

     

    to be sure how much RAM VE /VI takes always watch the task manager's process tab, maybe even inserting the virtual memory column - if MemoryUsage drops without reason (unloading an instrument) than the OS has tricked out the application ... i noticed that on XP and VISTA 64 on a 8 GB machine when loaded samples in VE went beyond ~7,5 GB ... nothing what makes sense of course, i've just been curious what happens ...

    christian


    and remember: only a CRAY can run an endless loop in just three seconds.
  • last edited
    last edited

    @jbm said:

    Since we still don't have a genuine 64-bit Mac OS, and most people aren't running XP x64 or Vista 64 (with appropriate drivers, hosts, etc.), they've made something that will not only work "in the meantime", but will also address the maximum possible RAM *now*. Nice decision, on their part, I think. --- J.
     

    J.:

    According to Apple, this is not quite true, Leopard is a genuine 64 bit Mac OS: "Leopard enables developers to build complete 64-bit applications using the Cocoa, Quartz, OpenGL, and X11 GUI frameworks. You can even use 64-bit Java on capable Intel processors. And the 64-bit and 32-bit versions of the libraries are built from exactly the same code base, to ensure a consistent experience for both developers and users." 

    Currently there is no Leopard compatible 64-bit of VE - hence the need for the workarounds mentioned. There is a complicated history behind all of this that has been discussed on other threads here - - suffice it to say that you'll notice the absence of mention of a 64-bit framework for Carbon - - at the WWSC 2006 Apple stated that it would release a 64-bit version of Carbon, then, a few months before the release of Leopard, Apple announced that it had decided not to do so - - a decision that stymied many developers. 


  • yeah, that was a obviously a typo: it should have read "genuine 64-bit Mac OS _build_"... I realize the OS has full 64-bit capability. I'm also aware of Apple killing 64-bit carbon, and moving forward with 64-bit cocoa only. And also that the move to 64-bit VEs is dependent on Trolltech getting its Cocoa-ized build of Qt done and in VSL's hands. Actually, I'm not sure why this reply to my statement came up so late... This has all been fairly widely known for a few months now. You'll notice that the post you've quoted from me was from almost 5 months ago. :-0

    J.

  • last edited
    last edited
    "It appears that VE (standalone and plug) as well as VI use approximately twice as much RAM as it should, as indicated in the Activity Monitor. any suggestions would be very helpful. Thanks VE (build 2869) VI 1.14 Mac OS 10.4.11 MacPro 2.66 Dual-Core 8 GB RAM" ddunn.
     

    @cm said:

    ddunn, what makes you assume VE or VI is using twice the RAM as it should? each loaded stereo sample needs 64 KB memory for the preload buffer, the application (or plugin) as such also needs some MB of course ...

    please note that RAM usage in the activity monitor will show a certain amount of used RAM even if you unload some instruments due to memory management - loading the same instrument again needs only to restore the pointers then which speeds up the process, this memory can be used by other instruments when needed though ...

     Hi Christian- or anyone else in the know.
     Maybe I'm missing what you mean in your reply here, but having just loaded up a second VE2 with 3 woodwinds presets,totalling 891MB, my available RAM went from 7.17GB to 5.16GB!
     Is this normal?
     Colin

  • are you referring to RAM or MEMORY? please consider memory definitions in OS X - only the number for *wired* is memory located in RAM, so loading 891 MB should increase this number by 891 MB (add some MB for additionally opened instances).

    christian


    and remember: only a CRAY can run an endless loop in just three seconds.
  • last edited
    last edited

    @cm said:

    are you referring to RAM or MEMORY? please consider memory definitions in OS X - only the number for *wired* is memory located in RAM, so loading 891 MB should increase this number by 891 MB (add some MB for additionally opened instances).

    christian

     

     Cheers Christian.

    Just lost as to why it loads into 'Wired' and additionally roughly the same as 'Inactive'  thereby reducing 'Free' by 2GB.

    That besides VE2 is now crashing as soon as the total wired memory goes over 3GB. This is with either 2 or 3 VEs none of which are near 3GB in themselves. My understanding was that every instance of VE could address 3GB  by itself.

    I am using VE as a plugin and have had no problem processor-wise with 30 odd instruments over 4 VEs, but now having 11GB RAM have been attempting to load presets and VE is consistently crashing at the same point. Logic remains active.

    Additionally, as soon as VE reaches 2GB in Real Memory in Activity Monitor, the RM figure jumps to 16,777,216.0 and remains there.

    My system is MacPro 2x 2.66 Ghz Dual Core, Logic 8.0.2, OS10.4.11. The same happens with last 2 versions of VE.

    Any ideas? Cheers..

    Colin


  • last edited
    last edited

    @ct1961 said:

    as soon as VE reaches 2GB in Real Memory in Activity Monitor, the RM figure jumps to 16,777,216.0

    a known bug in OS X, caused by using signed instead of unsigned integer resp. interpreting an unsigned integer as a signed one (max range for 32bit integers is 2^32-1)  what somehow reminds me to a quotation attributed to Bill Gates: “640K ought to be enough for anybody.”

     

    more info on memory definition in OS X here


    and remember: only a CRAY can run an endless loop in just three seconds.
  •  Read and understood! Cheers.

    Am I right in my belief that I can open up to 4 VEs as plugins in Logic with each addressing up to 3GB? The crash is occurring at a total of 3 and a bit GB wired.

    Colin


  • well, the 32bit nature is a real hindrance ... usually i'd say you should be able to load about 3.2 GB, we can reproduce that everything gets unstable beyond 3.5 - 3.6 GB, but some reports indicate this can also happen with just 2.6 GB - it might depend on configuration and/or condition of computer ...

    i'd like to leave more detailed help to our mac support though, christian


    and remember: only a CRAY can run an endless loop in just three seconds.
  • Cheers....


  • last edited
    last edited

    @ct1961 said:

     Read and understood! Cheers.

     

    Am I right in my belief that I can open up to 4 VEs as plugins in Logic with each addressing up to 3GB? The crash is occurring at a total of 3 and a bit GB wired.

     

    Colin

    Hi Colin, I may be wrong and shot down in flames but as far as I am aware however many instances of VE you open as a plug-in the 3GB (approx) limit is across all of them rather than each instance. I've got 32Gb of RAM and currently VE's start creating a problem with total addressed memory around 3.2GB (though I take this reading from the virtual memory column in Activity Monitor as this, for some reason, seems to more accurately chart when apps are near their max RAM. Logic, by the way starts to become unstable after 3.5GB and unusable after 3.9GB on my system. Regards, Julian

  • Hi Julian. 

    I believe you're right. I was sure I had read a post, more recent than above, that I could open 4 with up to 3GB each but obviously not. Will now have to figure out how to route a standalone version back into Logic.  Cheers...

    Colin


  • I don't use the standalone but I think each one of these has it's own RAM allocation ( 2 VE standalones = 6GB max) Julian