If you sort the processed by name, all GP instances will be next to each other. Then you can see easier what the process-ids are. I think I recall situations where taskmanager by accident showed the wrong icon. The pid is more reliable.
Ram is allocated and released by the processes themselves as long as they run. If a process is told to quit, the program itself and all (well-written) libraries will release the memory they allocated. If a program allocated 10,000 chunks of memory, it will release these 10,000 chunks of memory separately. Thatās why it can take a lot of time for a process to quit: overtime, without you even noticing, it might have allocated millions of (little) chunks, but when you quit, the time needed to release all of them might really add up.
Terminating the process leaves the task of freeing the memory to the os, but the os has no idea what the process was trying to accomplish and just put back all the memory that was allocated in the free memory pool. Thatās much faster.
Keep in mind that by terminating the process closing is much faster, but it is possible that the process itself would have done something useful, for example writing cached data to a file or something. Terminating will skip that. Luckily nowadays most programs are written in a way that this is not needed, but there might be other things, especially with GP because it potentially hosts a lot of 3rd party plugins of which it has no control in this respect.
It was brilliant, so thanks very much. Just wondering - does the Windows swap file help much in freeing up ram? I read somewhere that it could be deleted when you have plenty of ram (I have 32gig, and I use predicive set to 1). So I deleted it but would reinstate it if it would help in this situation.
The swapfile has more usages than just swapping out memory: some apiās need the swapfile, for example memory mapped files in some circumstances. My advice would be to let Windows just handle it. Windows will only allocate space if thereās too much memory pressure. And Windows is smart enough to not swap out memory thatās really being used. But you are free (of course) to ignore my advice: If something works for you, it works for you.
Hope this addition is appropriate. My monster gig file contains 550 rack spaces. Iāve tried three time to load some audio files that total 10 meg and GP wont accept them, but just shuts down. My question is this:
Is there a total number of rackspaces that GP will accept into a large gig file?
Theoretically no - but your rackspaces have plugins and they are using RAM too. However, if youāre using predictive loading, youāre only loading one rackspace at a time so that shouldnāt be an issues.
Loading audio files is totally separate from rackspaces. If GP is shutting down then thatās basically a crash and we need to see why - a crash report would be helpful. That said, are you using the streaming file player or the older audio track player?
)