Vienna Symphonic Library Forum
Forum Statistics

186,759 users have contributed to 42,477 threads and 255,921 posts.

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

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries
  4. Large Address Awareness?

  • Large Address Awareness?

    D
    D

    Am I right in saying that VE3 (Windows 32bit version) is not Large Address Aware?  I had terrible trouble trying to load a project recently which seemed to be fixed by patching the VE3 VST plugin dll with the freeware LAAtido utility, which gives programs Large Address Awareness.

    If this is a problem, it should be fixed soon!  It crops up when using 32bit host software (for stability) in a 64 bit OS (for VE's access to memory outside the host process), in cases where the host memory is being heavily used (up to near the 3GB limit of 32bit software within a 64bit environment).

    Cheers

    Dan

  • D
    D
    last edited
    last edited

    @dagmarpiano said:

    Am I right in saying that VE3 (Windows 32bit version) is not Large Address Aware?  I had terrible trouble trying to load a project recently which seemed to be fixed by patching the VE3 VST plugin dll with the freeware LAAtido utility, which gives programs Large Address Awareness.

    If this is a problem, it should be fixed soon!  It crops up when using 32bit host software (for stability) in a 64 bit OS (for VE's access to memory outside the host process), in cases where the host memory is being heavily used (up to near the 3GB limit of 32bit software within a 64bit environment).

    Cheers

    Dan

    If you are using a 64bit OS, you shouldn't be using the 32bit version of VE anyway. I'm running 32bit Nuendo in XP64, and am currently loading around 14GB. I'm not even sure why the 32bit version would load. I can't remember ever being given a choice. I think there is something else going on here. Is it possible for you to give specs of how much memory, mow much is being used by each application etc.

    DG
  • D
    D

     hi DG.  I don't think I explained myself clearly enough.  Yes I am using the 64bit version of the VE server, and therefore loading 64bit instances of Vienna Instruments, and therefore happily loading up over 10GB of VSL samples.  This isn't the problem.

    The problem is with the VE3 vst plugin that runs inside Cubase - that tiny dll which communicates with the sever program outside the host process.  Now, if you have a 32bit host then both that host and the VE3 VST plugin dll are 32bit programs, not 64bit.  Ok, so Cubase is Large Address Aware, so can use over 3GB of RAM within the host process.  Because the VE3 VST plugin dll is NOT Large Address Aware, the problem arises that in a very full Cubase project, with over 1.5GB of RAM used internally within the host process, if the VE3 plugin is quite far down the loaded instrument list, and therefore during loading of a project loads after all your other samples, it needs to access a higher area of memory, will not run and therefore crashes the project.

    So, you see I'm not saying that I can't load lots of samples into VE3, I'm saying that in certain high host-RAM circumstances the Vienna Ensemble VST plugin will not run inside Cubase in the first place, because it is not Large Address Aware.

    It's no big deal - as I say the freeware program LAAtido patches the VE3 dll and fixes the problem.  It's just that it would be nice if it ran out of the box, and of course some people out there will not understand this problem or know how to fix it. They will just find their host crashing on loading projects and not know why.
  • M
    M

    dagmarpiano,

    Thanks for reminding us about this. I hadn't thought of the scenario you are describing. I have now added Large Address Awareness to the VE plugin, will be available with the next VE update.
  • D
    D

    Good news!  Very pleased to have influenced a tiny bit of VE development, even if it is a problem that will soon go away (when all software is 64 bit!).

    Thanks

    Dan

  • D
    D

    Good to hear that this will be solved. Good catch, Dan. [:D]

    DG