Read this for max GStudio poly!!!!

[Simon Ravn]

This is really Donnies tip - THANKS Donnie AGAIN!!!

I couldn\'t get past some 80/86 voices. I\'d been following all those \'optimise tips\' with vcache min/maxfiles to 4096 or so. BUT Donnie had it set to some 48000. So I tried putting mine to 50.000 and BINGO, 140 voices without a problem.

TRY this....

[Danny Lux]

How much RAM do you have? I treid changing the settings with no real significance. Is the vcache setting in the system.ini? Currently that is where mine is, but perhaps that is not where it should be.

[Simon Ravn]

I have 192MB and yes, it\'ll eat some memory to add vcache, but it\'ll make a big difference to performance. At least it did here and for Donnie too. It is in system.ini yes... You should see your HD led a lot less on during GS playback (apparently because it caches more of the sample) when you have added the extra cache.

[Cheez]

Yup! Works for me too! The vcache should be set to 25% of your RAM. I have 384MB RAM - my vcache should then be 25% x 384 = 96MB or 98304 kB (ie 96 x 1024 - remember vcache is in kB not MB). My polyphony increased from 64 to about 100 (I\'m using PIII 533 with 2 UDMA HDD, Echo Gina, all previously mentioned optimizations applied).

I\'ve yet to try using this setting with digital audio recording. Anybody?

[LHong]

Hi all,
Try this formular, based-on your DRAM:
To determine the best value for your computer, devide your installed RAM amount in MB by 4 and multiply the result by 1024.
In your case (192M) the Formular should be like this:

192/4=48 -> 48 x 1024 = 49152

\"[vcache]
MinFileCache=49152
MaxFileCache=49152\"

Simon, how do get 50000 compare to 49152
That good guess! try this.
Hope that it would helps,
Regards,

[Simon Ravn]

Well I don\'t think that little difference means a lot. I tried fooling around with everything from 16384 to 50000 and the higher the better it seams.

[rbtweaker]

LHONG-For your formula-I think you can simplify:Multiply RAM x 256, or in your example, 192 x 256=49152

[Danny Lux]

I have tried setting my vcache to 98304 since I have 384 megs ram. The polyphony does not change. Using the Truan Steinway B, I get about 110 voices of polyphony on 2 different machines, 1 is a PIII 500, and the other is a PII 400. I would think the 500 would give at least a few more voices. I have read how others are increasing their vcache and seeing significant polyphony increases. I would appreciate any suggestions anyone has why I, and probably some others, are not seeing changes when vcache is increased.

[Simon Ravn]

I don\'t think you\'ll get 160 voices from the same instrument...?

[cc]

There are many different variables that affect polyphony - but as to vcache I suspect the following will hold true:

The more instruments you play simultaneously, the more splits in a particular instrument, or the longer the underlying samples, the less a particular vcache setting will help.

Also, if you play many different notes without repetition (e.g. C3 D3 E3 F3 ...), I think vcache will help you less than playing repetitive patterns like C3 D3 E3 C3 D3 E3.

Its all just a matter of what can fit into the available vcache area and how long it can stay there. Some data are inherently more cacheable than others, so it also depends on the individual instrument.

I would think in Danny\'s case, doubling vcache should show some difference. (Note: see below, this may cause trouble elsewhere). Of course there are other factors determining polyphony, like soundcard drivers, motherboard, hard drive, drive controllers, etc.

In my experience, certain systems will give less polyphony than expected (i.e. when you get 90 voices on an 800Mhz machine), because of suboptimal performance of the hard drive controllers (even if all drives are on separate channels). Sometimes using a plug- in SCSI or IDE card is also not a good idea, since it seems they can add significantly to the effective access/seek time. (I have seen 33ms thru such a card to a 9ms drive!).

In these cases, increased vcache may show significant performance increases, because it is counteracting a problem that crept in somewhere else.

It also seems to me that timing is an issue: if you are triggering multiple instrument notes at exactly the same time, chances are you will strike a lower polyphony limit (at least in my system).

Increasing vcache basically attempts to buffer as much of your instruments in RAM as possible, which is like going back to the RAM-based sampler...

Just a note: increasing vcache also steals ram from Giga, which means fewer available instrument \"slots.\" I.e., it seems that if you assign 25% of ram to vcache, you can only safely load instruments until the GSt memory indicator hits 75% - or face a crash.


[This message has been edited by cc (edited 07-05-2000).]

[Simon Ravn]

Well that last part with 75% or face a crash is an obvious bug in the way GStudio sees/allocates memory.

[cc]

Actually it can be quite handy to know the percentage of total memory you are using, provided that you know and understand your vcache settings. Personally, however, I think that users should never need to be familiar with the deep down internals of the thing to get proper work done...

As to it being a bug: I presume Giga has to \"lock\" the memory it uses, to stop windows from paging/swapping it out. Some operating systems are notorious for \"overcommitting\" on such locking - typically the OS promises more memory to the application than is really available, because it hopes to have reclaimed sufficient resources before all the apps \"call in\" their claims. This gives the appearance of faster load/run times.

I am not sure what win98se\'s position is on this, but it may well not be a bug in GSt, rather a \"conflict of interest\" betweem GSt and Windows. This is the price you pay for running a hard-core DSP app under an all-purpose OS...

[rr]

Well, this is all a little confusing, because I\'m sure that I saw a recommendation on this forum to set vcache maximum and minimum to 0! The 25% settings are recommended on the cubase for Windows users\' site (although I think the recommendations were written when 64M of ram was a lot).

It would be nice if the guys at Nemesys could update their troubleshooting and faq pages with much more detailed information on how to get the most out of GS/GSTUD. (Well, I know everyone is busy, and of course I would like the patch as soon as possible, too, but in the long run it would save the technical support people a lot of time if more information were available).

cheers

[This message has been edited by rr (edited 07-06-2000).]

[Gulliver]

Well, this is all a little confusing, because I\'m sure that I saw a recommendation on this forum to set vcache maximum and minimum to 0! The 25% settings are recommended on the cubase for Windows users\' site (although I think the recommendations were written when 64M of ram was a lot).

I\'ve found on my system that the setting of vcache values is a question of balance or equilibrium. If I set vcache to 0 I\'m guarenteed to not get polyphony above 40-50 (and this on PIII550/256mb!)
On the other hand, if I set vcache to a very high number (ex.75000), I will be lucky to load more than 5 or 6 giga files before my system croaks and runs out of memory. The former has to do with how important the vcache settings are to gigastudio\'s sampling engine, the latter has to do with a high vcache setting eating up valuable RAM space.
If a cache of any type gets too big, its usefulness drops off and it becomes, to a
certain extent, a dead weight
I like the suggestion that you should set vcache to %25 of your total system RAM. I think that is a good general rule but fool around with the settings to achieve the right balance for your system. Some people with fast, powerful systems might be able to get away with \'0\' under vcache but you\'re much less likely to get pops, drop-offs in playback with vcache > 0.

Regards,
Gulliver.

[killerbobjr]

>>>>
I like the suggestion that you should set vcache to %25 of your total system RAM. I think that is a good general rule but fool around with the settings to achieve the right balance for your system. Some people with fast, powerful systems might be able to get away with \'0\' under vcache but you\'re much less likely to get pops, drop-offs in playback with vcache > 0.
<<<<

Setting Vcache to a number greater than 0 just allows cacheing of the most recently used samples in memory, hence reducing the hard drive requests. If you are playing a piece in one key, with short note durations, Windows will automatically cache the most frequently used disk sections (our samples) into memory. But as soon as you play long notes or start playing a lot of different notes, watch out! The cache gets flushed and you\'ll start hearing crackle.

What we really need is a user settable value for Gigastudio\'s pre-fetch queue. According to the Conextant patent, it\'s 32 or 64K bytes for each sample loaded. At 16 bits, 44,100 Hz, that give GSt about 0.74 seconds of playback (at the root frequency) for a 64K buffer before it has to fetch the next part of the sample. If your disk has an average random access time of 8ms, that means you can play a maximum of 92 different samples (assuming no other processing overhead) before you have to fill that playback buffer. Of course, making the pre-fetch queue bigger takes up a lot more memory for large gigs. For something like Gigapiano, that\'s 88 notes x 4 velocity levels x 2 channel stereo samples x 64k = approximately 45MB, doubling it uses 90MB which gives you 38MB left for Windows in a 128MB system. Can you see why it\'s much more important to have a faster hard drive than a faster CPU or more memory to keep playback crackle free?

[Bruce A. Richardson]

I\'ve been experimenting with the various VCache settings this week.

I think that several people have identified this, but it bears repeating: Your increase in performance is proportional to the amount of repetitive, short notes in your particular application.

For instance, I have a very thick, very up-tempo orchestral march which can choke my system completely with VCache set to 0 or even up to 8mb of cache. But as soon as I get to 16mb of cache, the whole sequence plays smoothly. If I bump it up even higher, eight to sixteen bars can go by without any disk activity at all.

On the other hand, if I decide to sit and play solo piano with the pedal down 100% of the time, I get no benefit from adjusting VCache, since I\'m filling the cache with single, very long notes. As soon as I change to another long note, I\'m out of cache and Windows flushes the data and starts over. I get no more polyphony, since I\'m back to streaming essentially every sample.

So it stands to reason that the VCache tweak should actually be invoked for specific purposes, rather than as a panacea. At times it might be beneficial to use it, especially with lots of quick repetitive samples being triggered. Downside is you lose RAM for loading more samples. There seems to be no performance *hit* associated with increasing the VCache size, so it\'s more a decision based on how much RAM you have to spare for it.

[rr]

I tried playing around with the settings, using the Steinway-B, after checking to see how much free ram I had when the piano was loaded. (My system has 192M now; I\'m thinking of adding more). I tried setting vcache to around 30%, since it seemed that much was easily available, and noticed some improvement. (I play a lot of repeated notes, too, when soloing piano).

What made even more of a difference, was to set the \"read-ahead optimization\" to maximum, instead of \"off,\" and this seemed to help quite a bit to reduce pops. Setting this to \"off\" is a recommended tweak for audio, but on my system (at least yesterday!!), setting it to maximum along with increasing the vcache seemed to help.

(All this is playing live, by the way, not using a sequencer).

(Incidentally, most of the pops seemed to be coming when I pedalled; if you lift the pedal and put it down again quickly, GS picks up the notes that were being sustained before, only at a point further along in the fade. This is good, because on a real piano the sound won\'t die completely on a quick pedal, but it also means, I presume, that GS/ram/HDD are trying to produce a whole lot of notes at once, which is probably where the popping came in).

[rr]

[QUOTE]Originally posted by killerbobjr:
[B]>>>>

What we really need is a user settable value for Gigastudio\'s pre-fetch queue. According to the Conextant patent, it\'s 32 or 64K bytes for each sample loaded.


Yes, this would be really good. If you had, for example, 512m of ram, and had the choice of loading perhaps the first 450M of one of the pianos (or whatever) into ram, then hard disk access would be greatly reduced, and things would really rock.

cheers,

[vb]

These optimizations are great for pushing every last voice out of the system with GStudio. My guess is this was never quite so necessary with GigaSampler since it only had 64 voices, and it appears that everyone here is pushing way past that.

One interesting thing though, if you went back to turning off the optimizations and hearing some popping at high polyphony (> 100 voices), and you did a 16 bit capture at the same time (using the GigaStudios output record) - are you hearing the popping in the captured file when you play it back also? Just want to see if everyone is seeing the weak link before or after the audio gets to the sound card.