Vienna Symphonic Library Forum
Forum Statistics

196,053 users have contributed to 43,014 threads and 258,388 posts.

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

  • Can any WinXP 64 users verify this?

    Are you guys not noticing this behavior?

    Anyone at VSL have any info?

    Thanks,

    David 


  • ohhhhh yeah!!! I've having this problem since I purchased the my first collection. I am using a Mac Pro right now. Its very fustrating and not many people seem to know about or even care beacause I never get many responces back on it. Maybe its just us two. lol


  • david, i took the liberty to edit your post because it was almost unreadable ... at least for me ...

     

    ktnujynisis, you are running XP64 on a macPro? interesting - would be great to know from where you got the drivers, i've been searching for some a while ago without success ...

     

    the assumed memory leak, i can't confirm unfortunately (or should i say fortunately?)

    my XP64 SP2 here starts with a commit charge of 280 MB and after starting up a VI stand-alone (1.12 - build sep 20 2007) it is 312 MB (memory usage for VI is 41.260 KB)

     

    loading and unloading patches/matrices leaves a little additional amount left in memory (~3-5 MB) but this is just related to the pointers which a allow a much faster loading after the patch/matrix has been unload.

     

    christian


    and remember: only a CRAY can run an endless loop in just three seconds.
  • So far on XP64 I have no problem either.

    Regarding XP64 on a Mac Pro. It can be done. Not for the faint hearted though!

    DG

  • I too use Sonar 7 Producer Edition and experience memory issues.   Perhaps it is a Sonar specific problem?   Christian, can you test with Sonar?

    Best,

    Jay


  • Carriage Return don't work when I post from a Mac machine, I'm at work. Its not a Sonar issue. When WinXP 64 boots up it uses 198mb of RAM then when I load the VSL VI or Ensemble the RAM skyrockets to almost 1200mb! What is requiring that 800mb of RAM when nothing but the VI with no patches loaded is open? Could it be bad RAM? Thanks, David

  • ktnujynisis, Can you describe your issue?

  • This is kind of interesting... for me, the problem is quite similar to DM33, though not as bad. I boot to 317 MB committed. After loading a single VI Standalone (no samples loaded) it leaps to 863 MB committed. Also in a similar fashion, the Processes listing doesn't give any indication as to where this memory might have gone... Any idea what this could be, Christian? Maybe a particular hardware-configuration thing? My setup:

    Asus P5K-Premium
    Core 2 Duo E6750 2.66 GHz
    8 GB RAM
    3x Seagate Barracuda S-ATA
    RME HDSP9652
    Windows XP x64, SP2

    Maybe this sounds silly, but could it be related to multiple Vienna Keys? I had a 3 machine setup, and thus have 3 keys attached to my single new machine.

  • Hi jbm, thanks for posting! Sounds like a very similar issue as mine. I only have 1 key. I have the Extended Cube, Ext App Strings, Ext Elements, and Bosendorfer. Could it be the amount of licenses in the system? But still the Task Manager is not showing where the RAM is going. Why in the world is the Carriage Return not working? Making it very difficult to read and write threads. Is there fix I don't know about for Mac users? Thanks, David P.S. - one more question for you - when you shutdown the VSL VI or VE do you get your RAM back to 317mb or close? I don't, its stays at 1200mb.

  • Jay, how about in stand-alone mode? My issue is not affected by Sonar 7 Pro which is using RAM as it should. David

  • Hey David. Just type "BR" in angle-brackets to get carriage returns. No magic on Mac, I just do that all the time. Hopefully it will be fixed one day...
    But more importantly, hopefully we'll figure out what's up with the disappearing memory. I don't have anywhere near as many licenses as you, just winds I and II Standard, Brass I Standard, Chamber Strings Extended, and Solo Strings Extended.

    J.

  • ...I don't suppose, David, that you've done an actual crash-test on how much memory is really available (or used)? That is, have you ever just loaded samples until it crashes? Just to see whether that 800 MB is _really_ gone, or if it's just the Task Manager messing up. Might be worth a try. I could try it on my machine, but I can't do it just this minute...

    J.

  • The only thing I have looked at was to make sure that the VI was showing the same amount of available RAM as the Task Manager. It shows the same. I'll try to load presets until the system crashes, sound like fun. Will have to wait until I get home from work tonight. Will keep the Forum posted - pun intended :-) P.S. - trying to use the BR bracket suggestion but it not working - is it these {BR} or these [BR] ? neither work

  • hehe... I was wondering whether I should post the actual characters... but I can't, of course, because the system sees them as commands, not characters!
    It's shift-comma, shift-period.

    cheers,
    J.

  • Thanks!
    David

  • test &lt; &gt; /< /> ...

    david, i have not enough 64bit machines currently to check if this effect shows up in another configuration, but generally it doesn't make any sense to me ... is there a default fxp being loaded with the startup or something related to ASIO drivers or effects (samplitude involved)?

    christian


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

    I agree. It makes no sense and I have never seen this before on WinXP Pro 32-bit.
    Its very easy to test. Just boot-up WinXP 64 and don't launch anything just look at
    how much RAM is being Committed in the Processes tab. Its usually around 200-300MB.

    Then launch a blank VI stand-alone or VE stand-alone. Keep an eye on the Committed RAM
    amount.

    You should see the VI or VE RAM usage go up to around 100mb (I can't rememeber) but
    the Committed RAM goes up much farther. Mine hits 1200mb!

    I'm NOT using Samplitude, its not even installed.

    Not loading a default fxp either, no effects. My interface is a FireFace800 by RME.

    It would be fantastic if I could get some suggestions to try.

    Thanks for your help!

    David

  • mac pro. I've even tested my VI to the point to where I had no loaded patches, matrixes, or presets, and I had about 300mb left on a 3gb ram machine

  • This is my previous post that no one really responded to................ Maybe this will help!!............ Alright. First of all, I would like to say that I 'm not upset and I ABSOLUTELY LOVE VSL!!!! Ok, now that I got that out the way. I'm a new customer so I may be a lacking the expert knowledge. Ok, I've invested in a Mac Pro 2.66 Quad. I have 3gb so far. I am only running the Chamber Strings Collection. I am using Prottols as my Host. (ever since the new rtas). BUT I JUST CAN'T SEEM TO GET CONTROL OF FLOATING RAM. NOBODY RESPONDED TO MY FIRST BLOG SO I AM TYPING IN FULL TEXT DARNIT!!!!! I even tested it. My ram peaked at 2064mb. I loaded a simple matrix. Then I cleared it. When I cleared it, I never went back up to 2000mb. It peaked at 1664mb. Then I loaded a few patches and a matrix. After that I cleared it off. So when I checked my ram it showed 0 samples used and about 1400mb peak. I keep repeating the same steps with different combinations of patches and matrix files until I ended up with 300 mb WITH ABSOLUTELY ZERO SAMPLES LOADED. What am I doing wrong? eventually I couldn't even run my Protools because it had no space to work. Nothing could work in that matter. Even when I closed out VI and reopened it, the ram was still at the same spot. The only way that I could get my ram back was to restart my CPU. now thats not right is it? Am I not erasing the samples out of Ram correctly? Do I need to reload VSL. Whats the dealeo? Is it a Mac configuration issue? SOMEBODY PLEASE WRITE BACK THIS TIME!!!!!!!!!!!!!!!!!!! HELP! HELP!

  • Hi ktnujynisis,

    I'm sure VSL is looking into it.

    I'm frustrated too and would like an answer right away
    but its not that simple of a fix and needs some serious looking into.

    If we hang in there they will surely produce some fix or resolution.

    David