i feel i have to step in regarding the postings from chompy, galleddrim and kevin,

ahead have a look at http://www.glasstrax.com/Tips/gigaexpert/unloadunmapped.html">http://www.glasstrax.com/Tips/gigaexpert/unloadunmapped.html - if this helps anybody, feedback would be welcome.

the method, virtual memory is accessed by the system, is different in W95/98/ME and W2K/XP, as well as the allocation of memory-adresses.

it is not a long time ago, computers itself could not adress more memory than 512 KB - everything above was virtual (i.e. located on your harddisk) and W95/98/ME can access physical memory above in theory, but you will run into a lot of problems trying to do so.

W2K/XP can manage physical memory up to 4GB, although a single process can only use up to 2GB - and there are actually only a few motherboards out there, which can manage 2GB or more.

that means, that it has something to do with W2K/XP, because this kind of issues simply could not (or at least hardly) ocurre with former systems.

there is a nice tool in W2K/XP which has been mentioned: the task manager
using the tab *processes* you can select a column (menu view) and display the virtual memory used by each process. have a look at msg32.exe (which is part of the *endless-wave-engine*) to discover the difference in memory-usage compared with the display shown in GS.

the behavior you will notice is quite nonsense, if you have 1GB or more in your computer, as access to vitual memory is slow(harddisk!) and timeconsuming (kernel-process!) and might have been useful in W98/ME but is a handicap with W2K/XP in junction with big physical memory.
this process has simply not been designed to work with the kind of virtual memory in W2K/XP.

also this msg32.exe (notice: developed by conexant corp.) shows another bad behaviour in W2K/XP: it does not free memory if data is not used and from about 800 KB used memory and above it becomes unstable (looks like a kind of deadlock), crashes/frezzes the machine and leaves locked processes - forcing a scandisk during restart of your computer.

we have heard of only one machine until now, which seems to be able to handle 2GB RAM with GS - this is under investigation - nothing very special with this computer - maybe except it's running XP [;)]

generally there is not much difference between W2K and XP, maybe the *nice* surface looking like a playmobile-toy, maybe the bunch of assistents nobody needs. anyway you will need to disable a lot of services in XP to get the same performance compared with W2K, see
http://www.musicxp.net/ for details.

finally some points why users on a mac seem to be happier:
there is a lot fewer hardware for macs and therefore a lot fewer issues
you cannot *build* your mac, everything comes out of one hand
there is not as much to adjust, install, configure as in windows, so it feels you have to care only about your music (and the software to produce it)
the architecture of the G3/G4 is *RISC* and therefore faster on audio- and video-related processes as P3/P4, so even a *slow* mac gives you a practible performance
since macOS earlier than X is not multitasking, software for *near-realtime-tasks* like audio is written to work *bypassing* the system and therefore very close to the kernel

so there is not much, what can happen to a mac-user compared to a win-user, but hey: wait for apps running with OSX

forgive me, if my excursion was boring for you, beeing primary interested in music than in computers, but is not as simple as companies like to make us believe

christian

Thanks for the replies so far.

@cm said:

have a look at msg32.exe (which is part of the *endless-wave-engine*) to discover the difference in memory-usage compared with the display shown in GS.

I'm looking at msg32.exe in the task manager and it's only using 639mb. There's a few other processes running, but they're only using a few mb each, certainly no more than 128mb all together. So I should have about half a gig of memory still left free, of which gigastudio could use 361mb, but it appears to be ignoring it! Why is it topping out at 639mb? It's confusing. I'm new to XP as well so I don't know if there's anywhere where I can specify that GS should use more RAM... (I second the guy earlier who mentions Macs - after working on OS 9.2 for the last 6 months, coming back to windows has been pretty unpleasant...)

In GS, the 'memory' indicator is at 78%. I can't load in any more samples, no matter how small they are. I get an 'Error code: 5', then 'Unable to allocate memory...'

So yeah... if GS can use up to 1Gb of RAM, how can I force it past 639mb?
What are other people's msg32.exe's topping out at in terms of memory usage?

Any help, as always, greatly appreciated.

Cheers,

Ben

@Chompy said:

I'm looking at msg32.exe in the task manager and it's only using 639mb. There's a few other processes running, but they're only using a few mb each, certainly no more than 128mb all together. So I should have about half a gig of memory still left free, of which gigastudio could use 361mb, but it appears to be ignoring it! Why is it topping out at 639mb?
[...]
In GS, the 'memory' indicator is at 78%. I can't load in any more samples, no matter how small they are. I get an 'Error code: 5', then 'Unable to allocate memory...'

have you added the value of the virtual memory used by msg32.exe?
this (error 5, which obviously comes from GS, not from win) looks like a problem known from W98: if your virtual memory gets too big, some processes are not able to get free adresses.
by default W2K/XP reserves the same amount of virtual memory as you have physically installed - this is not always clever, if you have a lot of RAM.
try to reduce the size of your pagefile (= virtual memory)
right-click my computer, choose properties | advanced | performance options - see virtual memory - click change and reduce initial and maximum size to 512 MB (write down the original values, if you have to reset it in case you expect any strange behaviour - which should not happen, but who knows...)
you might recieve a warning saying *the system may not be able to create debugging information bla-bla - continue?*, click yes - you need to restart

what have you done? as you have 1,5 GB physical memory (fast) you limit the usage of virtual memory to 0.5 GB, setting both fields to the same value prevents *dynamic resizing* (slow kernel-job) an you will end up with a total of 2 GB memory, which can be used by applications.
(the minimum you are allowed to select is 2 MB - i choose this on a graphic computer with 2GB and it became incredible fast)
lets say 120 MB is taken by windows, so GS has plenty room left

virtual memory is mapped into a hig adress-area (above 3 GB), so hopefully you are save now to avoid this error-5 _and_ have more data in your fast physical memory

would be interesting, up to how much percent you get now and which chipset is on your motherboard (usually found as name of the ide-controller)

christian

I am reading a number of statements in this topic that worry me. I am afraid that the advise being passed is not accurate, complete or even true and I would seriously like to advise that you consult multiple sources for issues on OS versions, memory management, etc.

As far as I have understood it (a few years ago when I was working more actively as software engineer/consultant):
Virtual Memory is NOT the same as the swap file on disk. Virtual Memory is the entire system that can provide applications and services with a heap of memory blocks that the applications see as PRIVATE memory - the applications cannot see the memory of the other applications. This is what is meant with the word VIRTUAL.

Virtual Memory (VM) systems are meant for managing blocks of memory on behalf of the running applications and services. Swap files are always a standard component of such memory managers. The operating system can swap out the least recently used memory blocks from RAM out to disk, when there are no more free memory blocks in physical (fast) memory, thus freeing RAM memory. When the application needs to use information in memory blocks now residing on disk, the OS will make sure the contents are read back into physical memory, using a similar swap out/in scheme.
If you think about this, you should notice that the swap file is thus NOT some type of alternative type of memory management. Neither is it worse, or something to avoid. It is just part of a smart, larger system to provide all applications with more memory than is available in RAM.

Windows XP is actually Windows NT 5.1 and Windows 2000 is actually Windows NT 5.0. So, if you trust Windows 2000, it does not make sense to completely distrust Windows XP. They are very similar under the hood, and both (I believe) quite robust and stable systems, meant for doing a lot of complex things at (nearly) the same time...
Now, with GigaStudio, we are dealing here with a very special and dedicated type of application, that is built around the feature of LOCKING allocated memory blocks. This means that memory blocks, once allocated to GigaStudio, have to remain at a fixed location in physical RAM, and thereby severely limiting the Operatings System to constantly keep moving blocks around, merging and swapping them to disk, if the usage count drops.

This locking feature is typically meant for small and critical drivers and kernel-type of routines, interrupt handlers, etc. GigaStudio however uses it to "aggressively" try to get hold of a maximum amount of RAM memory, which is quite opposite to the goals of Virtual Memory managers.

Of course, the OS will not allow an application to lock ALL physical memory, because that would render the OS itself unresponsive or even out of service. Here lies a big difference between the Win95 family (95/98/ME) and the NT family. The former require only 64-128 Mb for itself to run in, the latter at least double that amount. Also, under Windows 98 the user can reduce the amount of disk caching (the famouse [vcache] setting in System.ini). Under the NT OS-es this is not possible, and the OS takes a much larger percentage of the RAM for disk caching. Please note, that disk caching has NOTHING to do with the swap file.

Finally, to wrap up, GigaStudio has a known bug that limits it internally to use only up to 1 Gb of memory (if you followed my explanation of locking), that practically means: physical memory. Under XP this bug has worse consequences than under Windows 98 because of the size of the OS and the amount of disk caching.

So, if you want to get the most out of GigaStudio, please use Windows 98. This is a far less complex OS than XP and gives you really 30-50% more samples to load with the same amount of RAM. Win98 may be less stable, but if you only use it for GigaStudio and once you have it running well, it will be solid as rock. Keep the machine clean from other applications, install 1 Gb of Ram and make sure to specify a setting for the disk caching.
I have tried the XP route as well, experimented a lot, but finally reverted to Windows 98 SE for GigaStudio. My sequencer runs very nicely on an XP machine.

For Windows 98 SE / ME only:
Specify in the [vcache] section in the file System.ini:

[vcache]
MinFileCache=32768
MaxFileCache=32768

If you do not do this, you may run into trouble if you have more than 512 Mb RAM installed.

Hope this long story clarifies some points about memory management in general.

Cheers,

Peter Roos
peter.roos "at" deltaworks.nl

@Peter Roos said:

I am reading a number of statements in this topic that worry me. ....

peter, you are fairly right from the point of view of a programmer, although even this is not the whole story.
i've mentioned before, W95/98/ME manages memory not in the same way as W2K/XP does and i'm sure, nobody would be interested in an excurse regarding page faults, stack, heap and similar.

the term *virtual memory* is commonly used for a swapfile, even MSDN (microsoft developer network) is telling us: *Virtual memory is the space on the hard disk that Windows 2000 uses as memory* and the wording in the taskmanager is quite the same - so i think everybody understands, what's meant.

fact is, that many users would be happy to use _more_ than 1GB, which is not resp. hardly possible with 98 (besides other issues with this OS, i don't want to expand here - you have mentioned one)
unfortunately the same with most (nearly all) W2K/XP installations - but not because of the operating-system or memory-management but because of the design of the endless-wave-engine (developed by rockwell 1996 for modems, iirc)

i will be happy to discuss with you further details via PM
christian

Thanks for the advice so far, but no further forward I'm afraid.

First I tried setting the virtual memory to 'No page file', which didn't help at all, then I tried, as suggested by CM, to set it to 512mb. This also has not allowed me to load any more samples. GS still shows that I am only using 78% of the memory. In the task manager I have over 500mb of physical memory free. msg32.exe is only using 639mb.

I will, if necessary, try running Win 98, but I don't see how this will help from a RAM point of view. Obviously 98 runs in less RAM than XP, but in theory, XP should have a whole 512mb to use, in addition to the 1Gb that GS should be able to reside in.

TASCAM are not replying to my registration data when I try to send it to them, so I don't have a reg code, so I can't download the public beta of GS 2.53 to see if that remedies the problem. [:(]

As for the type of motherboard chipset.. I'm not sure about this. The machine is a Matrix from these guys... http://www.meshplc.co.uk/

well, the struggle continues...

If you installed GigaStudio from the discs you got in your package, you may have severe problems. For XP, you need to install the version on the website...which is a full installer, not just an upgrade patch.

This may be the root of your problems. XP in and of itself is not unstable with Giga in the manner you describe.

The version on my Gigastudio installer disc is version 2.50.48, which is, according to the www.nemesysmusic.com website, fully compatible with XP. I have not installed version 2.53.00, which is labled as a public beta patch. I have not installed this for 2 reasons. Firstly, I have not been sent my registration / download codes, so not only can I not complete registration of my copy of Gigastudio, I also cannot download updates from their site. Secondly, I am wary of public betas as a rule. But, I would install this one due to the problems I am experiencing.

I don't understand what you mean when you say that there are no instability problems 'in the manner I describe', as there quite clearly are!

I'm not making this stuff up. [:)]
I wish I was.

@Chompy said:

I don't understand what you mean when you say that there are no instability problems 'in the manner I describe', as there quite clearly are!

I'm not making this stuff up. [:)]
I wish I was.

Your version is a good version.

What is your system configuration, including make/model of audio interface? Something is fishy. I'm not implying that you're making anything up at all. However, the behavior you're seeing is not typical, and there could be some issue with your setup which is causing the problems. Perhaps we can find it...

Bruce - it would be excellent if we could find it. [:)]
At the moment I'm very close to being able to run all I need in real-time on one machine - clawing back that 20% of memory would completely nail it.

The system is a Mesh Matrix XP 2200+, with an AMD XP 2200+ processor, running at 1.8GHz. 1.5Gb of DDR RAM. 2 HDs - One 40Gb system drive, One 200Gb audio drive, where all my .gig files reside. When running GS, it is the only program running on the machine, besides the VSL performance tool.

The midi interface is a Midiman USB Midisport 4x4, using the latest driver from the M-Audio site. The audio interface is an M-Audio Delta 44, which GS assures me is GSIF compatible. I'm certainly getting solid, pop-free audio, and 160 voices of polyphony. Again, using the latest driver from their site.

Hope that info gives you some ideas. I'm pretty much stumped....

Interesting. I've taken out one of the 512mb blocks of RAM, leaving me with just 1Gb. Now, gigastudio can load fewer samples than before, as would be expected. BUT, the 'memory' indicator is at 99%. Could it be that my problem lies with inaccuracies in GS's memory indicator? I can load more samples with 1.5 Gb of RAM installed, but GS's indicator says 78% at 'top-out' time, when it maybe should be saying 99%. So, with the full 1.5Gb installed, it looks like it is recognising the RAM, but not specifying its usage correctly in the memory indicator.

Hrrrrmmmm. I wonder. It still doesn't explain why my task manager says that I have 500mb physical memory available when GS says 78% full and doesn't let me load any more samples.

[Edit: Just had a look in task manager again. After having put back the 512 block to take me up to the full 1.5Gb, Gigastudio only uses 100mb more than it did before the block was put in. Not ideal.]

I agree with Peter Roos that Windows98se seems to run more samples than XP. A friend of mine tried both systems as an experiment with 512mgs of RAM and when he loaded the Gigapiano under Win98se, it took 12% of memory in Giga. Under XP it took 18%; we therefore concluded that since Win98 takes less RAM we can load more instruments and samples under Win98. Peter, can you tell me how to get to the "system.ini." file settings as every once in a while I get a blue screen message when quitting Giga telling me my system.ini. settings need a minimum stack of 5 pages. I haven't been able to find where I can change that but I'd especially like to set the vcache settings to what you specify. Thank you!- Frank

Wow, Frank - 50% more memory under XP!! That's insane.

Nothing for it then. Tomorrow I install Win 98. XP can go to hell in a handbag.

[8o|]

I've had an abysmal day today.

Boys,

this is simple maths:

1. As XP needs at least ca. 210MB for the OS, it is no wonder, that with 512MB RAM, you are able to load more samples under Win98SE, which will (e.g. with 98lite) only occupy ca. 80-100MB of RAM.

-Win98SE: 512-100=412MB for samples
-WinXP: 512-210=302MB for samples

2. Since Win98's VMM will refuse to boot with more than ca. 1000MB of RAM, we will be able to load up to 900MB max. under Win98SE - no matter how we set the vcache and/or limit the PhysPage. XP allows you to put in e.g. 1,5GB of RAM and when you have configured your system according to the TASCAM-guide, you will be able to load up to 93-98% shown by the GS-memory-meter, which equals around 1Gig for msg32. Lower results may occur and are part of the holy plan of the universe [;)].

-Win98SE: 1000-100=900MB for samples
-WinXP: 1500-210=1290MB for samples/limited to 1000MB max.

Conclusion: You will be able to load MORE samples using XP, in case you are not one of those "poor boys" that can't get their XP-system to load the max. Shit happens [:(].

So for me it looks like this (my experiences are based on Asus boards with VIA chipsets, Athlon processors and Maxtor drives):
Under Win98SE I always get intermitting glitches and or choking streams, whenever the polyphony is topping 140 mono voices. The same hardware under XP gives me rock-solid 160 voices; no glitches, no choking. And around 100MB of RAM more for samples. Under Win2000 I was not able to load more than ca. 600MB before the "message of death" <error 5> has been shown. This is at least what I experienced in the past year and I am sure, that other hardware might give you different results...

All the best

Roman

Hmm, that's a fairly patronising tone you have there Roman, boy. [;)]

Spoke to TASCAM tech support earlier. They reckoned one thing that has (perhaps inexplicably) solved this problem in the past is a reinstallation of XP, which I might try before I go back to 98.

Was just reading through this topic and remembering the days of 98 before I upgraded... and all the crashes. All my machines run XP now, and each one has 1GB or more ram. The one recently added to run SI strings has 1.5GB, and right this moment I am looking at it at 98% full in GS. There must be something odd in the combination of gear that is preventing your machines from running correctly, and I would suggest further reseach into the matter before returning to 98 (cuz getting it to work is SO worth this time both for memory and stability purposes.)

All the machines that run GS here are built the same, and all components were chosen based on a prior system that seemed infallable on xp. I always steered clear of AMD simply because of the difficulty in making certain all components were compatable with one another. It IS far less expensive and just as fast to go AMD instead of Intel, but the difficulty in choosing totally compatable parts scared me off and made me stick with Intel. These machines were not designed to be gaming speed demons or anything, just fast, stable giga machines that could handle what I threw at them. Perhaps I've just lucked onto a good combination, so I'll share:

(all machines) - Asus Mobo P4B
(all machines) - P4 2.0b (2Ghz) (400mhz fsb)
(2machines) - 2x 512MB PC133 SDRAM Samsung ram (1GB total on each pc)
(1machines) - 3x 512MB PC133 SDRAM PNY ram (1.5GB total)
(2machines) - M-Audio AudioPhile 2496's
(1machines) - M-Audio Delta 44
Maxtor HD's all (4x 45GB, 1x 60GB, 1x 80GB)
Using MidiOverLan for midi connectivity
Midi input from Roland full size to Midiman Oxygen 8 and then in via Oxy8's USB cable.

All 3 run on XP, and have been running like this for many long months now without any having crashed on me for any reason even once. Then again, I almost never even turn those machines off. I like em ready when it's time to work [:)]

Anyway, I guess the point of this post is just to say that it IS very possible to run GS solidly on XP and make full use of all your memory, even up to 1.5gb. 98 would probably be a step in the wrong direction. On the other hand, if that ends up being the only way you get that machine to work, then by all means, do it so you can get back to making music! [:P] Then build an XP-friendly machine later on.

Seriously, good luck with the comp, Chompy. I've been there myself and hated life for a while.

'xcuse me, Chompy, good lord - NO! I never intended to sound "patronizing", I rather loved to sound "petrifying" or even "paralysing" [;)]. - No, honest:

Sorry, dear. I really don't wanted that. I went ill yesterday and was in a somehow rude state. I know how it feels like, when you just can't get your gear running in an acceptable way; noone wants to be told then: "Hey, you poor su**er, look at me, it works great at my place!!" I didn't want to sound like that. To maybe give you something back:

Besides stability and performance there seems to be an issue under XP, you won't experience with 98SE: a loading slow-down someone over here already mentioned. It occurs on my systems at around 80% of load. Whenever I try to load a giga-instrument , which is part of a large sample-pool and doesn't use the whole lot of them, the loading starts to snail and takes minutes. The CPU-meter of the taskmgr slows down (usually the CPU shows a high peak after short while transfering samples to RAM before GS is done). The only way to get around this, seems to load giga-instruments that really take the whole pool, e.g. a full-version-piano. I successfully separated giga-instruments out of a large gig-archive (the ".gig" file explorer shows you) using the editor and the "save limited/check unreferenced samples"-function as a workaround. Such separated giga-files with only one instrument contained usually load fast even under high-load conditions. As I have been checking this out with Tom Hopkins, it was nice if someone over here would add his/her experiences regarding these slow downs. But I am going to get OT, sorry...

What I wanted to say is: if you can't manage to get XP to give you an higher load and if you can get your system running well under 98SE, it might not be the worst thing to do, despite the fact that I consider everything MikeG has said to be true. I have heard of many people with very stabil performance under 98, too. But as you WILL have to move to XP as soon as GS 3.0 might be able handle the RAM-limitation, the 98-system won't be your final destination, I guess...

Good luck


The Roman Patronator ||Qo== ......... (large pump-gun)

My apologies also Roman - I wasn't in the best of moods last night at all. [:)]

I would rather stay on XP than 98 if at all possible - especially seeing as (from Mike's post) it IS clearly possible to get past 78%. Just a little gremlin somewhere.

On the AMD / Pentium thing - I would always, always go for a Pentium if I was buying for myself, but this is a company PC, and it's company policy (for some reason) to go for AMD...

Thanks for sharing the 'lucky' spec Mike. [:D]
It's very similar to my own setup, Asus mobo, Midiman and M-audio interfaces. But I notice your RAM is not DDR, whereas mine is... and of course there's the AMD / Pentium difference.

If I get anywhere, I'll post.

I have to agree with what Peter has shared here. I can now say from experience on two different systems that "downgrading" from Win2000 to WinME has literally doubled the number of instruments that I can load. I think I mentioned in another post that addiding in excess of one gig of RAM while running Win2000 actually caused me to be able to load *less* instruments.

Actually, maybe I can try to test this myself again, and install XP on one of my Giga PCs, replacing the well working Win98 setup (with RME Hammerfall). I will first make notes on the memory load of my strings template, etc. After installing XP, I will then add 512 to the already installed 1 Gb. And let's not forget to make a good backup first [:)]

I have become curious again about this stuff.

Cheers,

Peter
trying to start fixing something that ain't broken... [;)]