Yeah - I know it’s not a very good thread title, but here’s what I mean. 5.1 on Win 10. Reasonable mid-power gaming PC. I can stress it with lot’s of layers/splits/effects, but generally everything stays “within range” - e.g. - it works without fritzing out on CPU overload.
So - this one Rack Space - it happens to be “Final Countdown”. - the last few times I’ve played it, at the beginning, it is going to 100% and cutting out. It’s got several layers of string/choir/bell-synth in the left hand pad, the main horn/synth part, and I have a guitar solo sound loaded to play the double lead with our guitarist. At the beginning, which is where I have the problem, I also have a SAFP playing (wind sounds and such) while I do the intro. (Of course this is where it would choose to crap out on me lol)
Generally, it stays in the 40%-80% or so range on cpu hit except for that unpredictable overload at the intro., but here’s what’s strange. If I turn on my computer, load up that song/rackspace, I can play it all day long and not get it spiking. However, if I’ve played a bunch of songs before this one, like having gone down the setlist until I get there, THAT is when I seem to have the problem.
Is it some how “accumulating” something in it’s processing and not fully clearing out what was there before? I don’t know if it’s related to specific rackspaces before it, but I did not have this problem until fairly recently. Is it possible it is based somehow on the order my songs are in?
This has smacked me at two shows, and I need to get it fixed. BTW, I am NOT using predictive loading, do not have any patch persist going on any rackspaces.
I’m running at 128, but strangely, switched it to 256 to test, and it made no difference at all.
Seems that you are using plugins which consume cpu even when not used in the active rackspace.
Please do a test and use predictive load set to 1.
This way you make sure that only 1 rackspace is loaded into memory and all plugins not used in the active rackspace do not consume CPU.
This is not a fault of GP.
2 Likes
As I stated in post, no predictive loading.
I might try bypassing different plugins and see if one particular one seems to be the culprit (even though, to some extent it is probably cumulative). Based on your description, I might try bypassing the SAFP first. But, then try other to see what really kicks up the problem.
For what its worth, I had real problems with crackling with a pretty powerful machine. In one case I had to set install a file (with the help of Frank1119) to get the “Ultimate Power” setting to stick. In another cases (again, with the help of Frank1119) I had to install Throttlestop. In both cases Frank1119 helped fix these (different) issues. Let me know if you want those links.
I’m pretty clueless, but maybe plugins in the Global Rackspace are adding to CPU. If so, may try bypassing them at least in that rackspace.
Maybe there is memory disc swapping going on, but with the SFAP it puts it over the edge? Could try the sound effects using the non-streaming sample player to see if that helps.
Good luck!
I think @pianopaul meant you should try this to diagnose the issue.
By using predictive loading set to 1, only the current rackspace is loaded and as a result of that you can rule out or confirm the possibility that in another loaded-but-not-active rackspace some plugin is eating the cpu while doing nothing useful
Also, is this from the NARF soundset? They can be very CPU hungry.
If so, there is a thread that notes that NARF often mutes unused plugins instead of bypassing them.
The thread (very helpfully) suggests bypassing unused plugins in songparts/variations where they are not being used instead of relying on (default) just muting them.
How do you mute/bypass rackspaces?
Ahh, I meant mutes unused plugins. Thanks. Fixed. 
So - Predictive loading did not yield any new info really.
I needed to deal with this practically with gigs coming up, so just went and “thinned out” my rackspace. Staying pretty low now. I have no idea why sometimes it would max out and sometimes it wouldn’t, but now I should be safe - I hope!
[quote=“kbmatson, post:1, topic:22828”]
Is it some how “accumulating” something in its processing and not fully clearing out what was there before?
Not sure if this is helpful, but I had an issue whereby after an extended editing session with several different Gigfiles containing 25 rack spaces each, I could not load a new GF for further editing. My solution at the time was to reboot GP and start again. When I posted about this issue a little while back, it was suggested that I bring up the task manager and check in there. So I did that when it happened again, and sure enough, several GP instances from past GigFile loadings were sitting there about 1/2 way down the list gobbling up ram (I have 32gig) and preventing a new GF from loading. So now, instead of using the red cross top right to dismiss a GF, I always use Ctrl/Alt/Delete. This clears the ram and I have not had the problem since. I have been assured that it is not GP that holds onto the ram, but the individual plugins.
BTW - I use predictive set to 1 and at present am experimenting with a huge Gigfile of 550 rackspaces, By using predictive set at 1, the Gigfile loads in about 3 1/2 minutes, and loading a new rs can take from 2 or 3 seconds to 10 or 11 seconds depending on the number of plugins involved.
