Is it possible to reduce the active rackspaces from 3 to 1 with scripting when predictive loading is on? (which I realize removes the ‘predictive’ element of the feature)
Or is it possible to have all rackspaces besides the selected rackspace off with scripting?
I’m about 48 hours old to scripting and I’ve been reading and trying to learn and just curious if this is something that’s possible via the user-end.
I’m sure one of the experienced community members can answer the scripting question, but it might help if you could explain why you’d want to do this. Of course, you could just have your gig file have only one rack space and just load different single rack space gig files. Are you having resource and audio issues?
Why do you need that?
Non-selected rackspaces are always not “on” in that they should not use cpu.
So, I am guessing ram is the issue?
RAM issue with just 3 rackspaces?
There is a whole lot of jumping around in rehearsals during the sound design process, building on a particular aspect of a song, jumping back to another song and copying in sounds from a part of that song and building on those sounds, etc. I am a hired gun and the sound work is done with all 6 members present and I do what the director says, so there is an unannounced pressure to be as efficient as possible, akin to working in a studio where you’re paying to be there and the smallest delays can feel bigger than they are because of the expensive nature of the work.
The time it takes for a rackspace to load from a completely off state is practically negligible when it is selected, but the predictive loading aspect of the previous batch of 3 rackspaces turning off and the two surrounding rackspaces loading causes a significant wait time. When I say significant, I’m talking maybe 8 seconds max, not a big deal in the grand scheme, but when experienced over and over with all eyes on you and your laptop, 8 hours a day, you can see how I’d be curious about eliminating the predictive aspect to eliminate the waiting. You repeatedly see the thing you need almost instantly ready and then have to wait for the other things you don’t need to also load.
There are almost 60 songs being rebuilt from the band’s catalog in GP for keys and another 40 to go, so there is a significant load time if predictive loading is off, which is fine for the start of rehearsals, but usually for one reason or another it needs to be closed and reloaded when we’ve gone down a rabbit hole changing up different rackspaces and need to just close and get back to square 1, which again is not really a big deal in the grand scheme, but it is stressful day after day when that time comes to close and reboot GP and people are inclined to disperse and refill water bottles and use the bathroom and the whole moment of concentration and working has halted, etc. It is significant enough that people on different instruments have learned that the keys player is using GigPerformer and they’ve learned about predictive loading being on & off, and why there is no wait flipping between songs when predictive loading is off, and the trade off that comes with having it turned off, which in a perfect world no one have any reason to notice or ask questions about what I’m doing.
That being said though, I will say everyone collectively loves GigPerformer, we’ve migrated from MainStage which caused an insane amount of issues, so there are no negative sentiments towards GigPerformer whatsoever, it is truly a godsend. I’m just exploring possibilities of increasing efficiency.
Also, amazing community! Thank you to everyone responding so fast!
Hmm, in your situation, it seems to me that you would be better off just loading rackspaces in as you need them rather than either predictive loading or loading the entire gig. Then occasionally just export them once you’ve changed/saved stuff. That way you’ll never really have a lot of stuff loaded in the first place.
I also wonder, given your situation, whether you’re using a sufficiently powerful computer with enough RAM for the task at hand. Maybe you’re using plugins that are really slow to load (wanting to connect to their home server perhaps) or wanting to load huge amounts of samples.
Finally, as far as working with other people is concerned, I learned a long time ago from a very famous and well-known sound designer who helped me out a few times, is that part of the job is managing the expectations of others. If others think everything they ask can be instantly achieved, then you need to correct their preconception 
To me, that sounds pretty much what he is asking about.
If you “loaded rackspaces in as you need them”, would that be the same as importing the rackspace? Or is there something different?
Yes, import them
I guess I just fail to understand this. 8 seconds? It takes as long or longer to mess around to import/export another rackspace. My normal gig file is 26 rackspaces with a number of variations, takes 40 seconds to load from scratch, I have predictive loading set at the minimum of three, a sample rate of 44100 Hz, 32 sample audio buffer size, CPU loading around 9% (variable up to 35% depending on the sample libraries of specific plugins/computing power for some specific effects plugins), and changing rack spaces is as fast as I can click the mouse/press a button. As @dhj said
But at 8 seconds, that doesn’t seem much to manage if that’s the time it is taking you to switch regardless of the manner in which you do it. I just must be misunderstanding the time factor you are describing.
I guess I’d also ask the retorical question… do you need a rackspace per song?
Can you reuse a rackspace for multiple songs by leveraging variations?
I’d personally dislike having to import rackspaces and then associate them into the setlists while in reharsals but maybe that is the best solution.
I have found I can cover a lot of ground with mostly using a single rackspace in my gig file, with about a dozzen variations and then for some songs have bespoke rackspaces for them vs. always making a rackspace per song.
Gotcha, thanks for the fast replies, I will try rethinking workflow and bringing rackspaces in as needed.
And dhj you had the right suspicion about the workload for the computer. As of yesterday night there’s just too much going on in the gig file and the backup computer wouldn’t work at all with predictive loading off and kept crashing with predictive loading on, so the main is now becoming the backup and they are ordering a new M2 Mac with 96GB RAM. The backup was a 2017 intel Mac with 16GB RAM, and the main was a 2021 M1 Mac with 16GB RAM. The cpu percentage usually hovers around 30% but the RAM wasn’t cutting it and there’s still 40 songs to go.
Thanks for everyone’s replies!
I wonder if it would be a good option to allow Predictive Loading to apply to only load the active rackspace.
I know it the term “predictive loading” technically would not really apply in that case. But, I would think that would be the easiest way to accomplish only loading the active rackspace. Just allow a setting in Predictive Loading to only load the active rackspace.
I think it is preferable to using an empty gig file and continually importing the rackspace you want to be use.
[Actually, if that was tweaked, might as well also add the option of loading that active rackspace and the one right after. Thereafter, the current options would work.]
Just my $.02 to consider.
Just to update - new MacBook Pro, M2, 96 GB unsurprisingly works great haha. It did not like any instances of Kontakt 7 VST3 at all, and switching to Kontakt 7 AU on all rackspaces has made it rock solid so far.
To revisit the question before I go down a rabbit hole trying - is it possible to reduce the predictive loading feature to just 1 at a time via one of the Gig/Global/Current Rackspace Script editors or does that type of customization not fall within the Script editing capabilities?
While the updated computer hardware has improved stability, and predictive loading is a life saver and makes things possible, the hardware has not sped up the song change times (we don’t have setlists so there is a lot of jumping all over the song list) and the seem to have increased with time and usage, so I’m still the last one ready to start on stage waiting for the three rackspaces to turn off and three new ones to load up when the actual load time/activation of just one rackspace appears to be near instantaneous, in addition to extra computer work that doesn’t need to be happening. I try to be cautious about best practices and optimizing CPU performance, turning off wifi, bluetooth etc. and having these extra rackspaces pre-loading unnecessarily preys on my OCD in the moment.
It is not life or death, we just have a very tight schedule in the coming months and this is the last opportunity for any pre-production tour prep work and I just want to cover my bases in regards to squeezing out max performance and eliminating any extraneous variables in my area. Thankssss!
Predictive Load is an option in the options window.
It makes no sense to change or set that in a script.
It currently won’t go below three rackspaces in the options window, so I’m wanting to get around that and get it down to 1 rackspace but also didn’t want to waste time trying if it wasn’t possible.
As PianoPaul said, predictive loading is an option. Just turn it off. The trade off might be a slightly longer time to load the next rackspace, but if you are jumping around the set list predictive loading won’t help anyway. Or you can have each rackspace as it’s own gig file and load your songs as needed. Or wait a little longer as this is reportedly getting updated in the upcoming new version release of GP.
Oh I didn’t realize that was possibly upcoming. I can def wait it out if that was the case. It would probably take me longer trying to get the script right myself ha.
Predictive loading turned off isn’t an option bc of RAM usage along with load time being so long we built in water/coffee/bathroom breaks in the past with the old Mac, and of course if it crashed on stage it would be out of the show for a long time during reloading process. The highly specialized nature of each song prevents sharing of plugins and reducing CPU usage and the nature of the sound design process, of which I am more of a technician following instructions, won’t come to an end point. Every rehearsal there are tweaks throughout the process and each hour gets its own time stamped gig file, so trying to maintain individual rackspaces outside of the gig file with their own time stamps is not feasible. I have explored several options trying to consolidate workflow and make the process smoother and more efficient and have circled back to this really just exploring further tweaking via 1 rackspace activation/load at a time to reduce extra computer processes that aren’t necessary and make things smoother. I’m happy to put in the time figuring it out, just looking for feedback on if it was possible before I spend time tinkering on something that can’t be done.
Loading one rackspace/predictive loading was discussed in a similar post and hints dropped about the upcoming version upgrade. Might be worth the time to read through the post and replies.
https://community.gigperformer.com/t/another-plea-for-a-single-rack-space-load-and-unload/14752/1