possibly ktnujynisis is running XP64 on a macPro? the mac people here don't allow me to do so ;-)
and remember: only a CRAY can run an endless loop in just three seconds.
-
same problem... different OS. Which obviously disconnects the problem to the operating systems or he OS's type.................??????????????!!!!!!!!!!!!!!!!??????????!!!!!!!!!!!!!!!!
-
-
@ktnujynisis said:
same problem... different OS. Which obviously disconnects the problem to the operating systems or he OS's type.................??????????????!!!!!!!!!!!!!!!!??????????!!!!!!!!!!!!!!!!Memory handling is so different for XP and OSX that you cannot deduce a connection I'm afraid. Mind you, you did say disconnect, thereby stating that the problem is not connected to the OS. [6]
DG
-
Just to let you know: I´m having the same problem on a G5 2 GHz Dual with Mac OS 10.4.1 and Vienna Ensemble. I hope the support is working on this, since adressing more Ram was one of the new features of Vienna Ensemble!@DM33 said:
I'm wondering why its only happening on so few systems.
Only a couple of people have mentioned the problem.
I would think it would be a bigger problem. It must be something
wrong with our specific systems. May RAM type or bad RAM or errors
on the hard drives.
David
-
I have to admit that it would be nice to know what's come of this problem. I haven't messed around with it lately, but I was having the same issue on my X64 system. I managed to make it completely reproducible, by emptying my Directory Manager, then loading instruments one folder at a time. The memory "loss" would increase proportionately to the size of the folder loaded, with the Flute Ensemble, for example, only losing about 3 MB, while the Violin Solo lost a whopping 32 MB.
Christian has referred to this as a data corruption problem with the samples themselves, but that's not too comforting either, as data corruption is a pretty major issue, and is generally caused by something. So the next obvious questions is, what's corrupting the data? And is there any way of tracking it down? Do we really just go ahead and spend x hours re-installing the whole library, in the hopes that it *might* fix the problem? Also, why does the problem manifest itself incrementally, as I described above, as I add folders? Does that mean each folder is somehow corrupted on my system?
Lots of questions, with very few answers. I can only assume they are, in fact, working on trying to track down the problem, and will post something when they have a better picture of what's going on.
J.
-
Hi jbm,
Thanks for your post. We need more people to mention this problem if they are having it.
I can't get any answers from VSL, although cm has tried to offer advice for which I am grateful.
VSL seem not to be able to reproduce it this problem. The one time they experienced it it was traced to a corrupt solo strings folder.
I have reinstalled winxp64. Then deleted my VSL content which is spread across 3 drives and reinstalled
all my 14 volumes.
With each volume install I checked the Directory Manager and each time I lost a little more memory.
Exactly as you describe. With some volumes losing much more RAM then others.
Can all of my discs be corrupt? They are all new and I ran chk dsk on every drive before installing the volumes.
Did not find even a single error.
Can all the VSL discs be corrupt? I store them in a dark, cool place and have only installed them once before.
Plus I have bought Bosendorfer, App Strings, and Elements besides the cube and they exhibit the same problem.
Last night I ran PerfMon, thanks to cm for informing me of it. Its quit a handy tool but it just showed me
that my RAM was being used not where it went.
I'll keep trying new things and hope something works. As it is I'm losing around 800mb of my 8gb of RAM.
Thanks,
David
-
@DM33 said:
VSL seem not to be able to reproduce it this problem. The one time they experienced it it was traced to a corrupt solo strings folder.
Oh, okay. I didn't realize they had traced it to a specific folder. But nevertheless, there shouldn't be a problem with a brand new install. The installer should be checking for errors, and should fail if any occur. I wonder if it could even be something as tricky to pinpoint as a particular drive and motherboard/chipset combination? Sounds far-fetched, but just in case:
Asus P5K-Premium
Seagate Barracuda 7200.10 series
J.
-
I´m not sure, if I have exactly the identical problem. (In my case I load logic, and everything is fine, until I load a Vienna Ensemble plugin, which claims to use 440 MB of samples, but in total I loose about 1,4 GB Ram) Would it help, if I send pictures of my activity monitor before and after loading VE?
-
james, david: apples and pears .... while david reports to loose 800 MB in commit charge just by opening the VE you tell us abot (loosing?) 32 MB when loading solo strings.
i wrote, that i could fix a similar issue david had removing a collection with obviously corrupt data.
some mac guys tell us they notice increase of the _inactive_ memory (i posted already a link to what inactive memory is) - so where is the common denominator?
sorry, either i'm too blind to see it or there is none.
each operating system has some sort of memory management which can in mosT cases not be detirmined by an application.
i would exclude reasons like chipset, memory, processor (except it is really faulty of course, but this would be another story) - more interesting would be *features* like pre-fetch, running services, pagefile settings and this kind.
see the thread about XP giga and memory management: defined situations give defined results, and even those differ between identical machines sometimes. we should choose a more systematic approach, because you have to know i'm not the engineer responsible for setting up your machines guessing your details - i can run a defined series of test on the few machines i have under my control and we can discuss issues, ideas and solutions here.
thx, christian
ps: of course a screenshot with all relevant information from activity monitor/taskmanager helps ...
and remember: only a CRAY can run an endless loop in just three seconds. -
Hi everybody,
I have to clarify my situation because I see it referenced incorrectly a few times.
My RAM gets lost EVERYTIME I run ANY VSL product!
It happens with VI, VE, and Directory Manager (DM).
When I launch the VI or VE during start up they do a scan for locations of the data. I can hear my hard drives getting scanned. It happens after the syncrosoft dongle light goes on and off a few times then the Committed RAM skyrockets.
It seems like its loading samples into RAM but I don't have any default patches or presets setup.
When I launch the Directory Manager it happens when I hit the Scan button. I can hear it scan my hard drives
and then the RAM skyrockets.
Its loading samples into memory??? but why?
If I shutdown the application the RAM never goes back down.
If I relaunch any of the applications (VI, VE, or DM) then they launch without taking
further RAM since the scan was already done previously.
I have to reboot the machine to retrieve my lost RAM.
Anyway, just wanted to clarify.
Thanks,
David
-
david, is it still the same issue we started talking about (commit charge increases, but we don't see any process listed using it)?
i had this too for a few hours but have not been able to get this (mis-)behaviour back so far ...
christian
and remember: only a CRAY can run an endless loop in just three seconds. -