original post here.
Continuing my work with plugin presets classification.
This project was started on Windows 10 (iMac 2012) and finalized on Mac Mini M4.
My 2012 iMac cannot open this gig file, I guess because it requires way more RAM than my available 8gb. Crash report gathered and sent.
The Mac Mini M4 with 16GB of memory opens it no problem.
All presets seem to work correctly. But let me know if otherwise.
Try predicting loading then
open an empty new gig?
set predictive loading, then open the gig file?
Predictive loading is a global setting? or is it a per project setting?
will try - although i did not have much luck with predictive loading on the iMac 2012.
I suspect that on such a old computer - plugins that take a lot of CPU won’t work very well when many instances are placed. I mean even on a Mac Mini M4, Augmented STRINGS takes 10-20% CPU just for a single instance.
Compare that with other plugins that only take 1-3% on the old iMac 2012 and on the Mac Mini M4.
Predictive load is an option you can set in the option window.
Then load your gig file
And predictive load is a global option as all options you can set in the option window.
But: each instance of GP uses its own options.
So for each instance you can set different options.
When you have loaded gig, change predictive load => the memory usage and loaded instances are automatically adjust.
A little bit difficult to explain, just do it and you see it.
Sometimes newer machines use more cores but the clock frequency is lower.
As GP now only uses 1 core => with lower clock more cpu is used for the audio thread
Predictive load does not lower cpu but is lowers memory usage.
did not work on the iMac 2012. it only has 8gb of RAM.
It crashed the entire computer - not just GP.
It made my screen resolution really low. had to restart computer.
That makes sense because:
I tried opening the same project on my Mac Pro (2010) running Monterey, and it opened it without a problem - because it has 128 GB of RAM.
This project takes about 50 GB of RAM. It goes all the way to 60GB of ram while going through the presets (variations). Probably it would take even more RAM if I were to open the plugin editors.
So this is not a problem I am describing for the iMac 2012 - predictive loading or not - does not work. Just more like letting users know this won’t open on older machines without enough RAM.
Augmented STRINGS is just very CPU and RAM intensive - so either need a newer computer or one that has approx 60 gigs of RAM.
Predictive loading with default size of 7 is nearly the same as predictive loading off - given that 2 of the rackspaces have 64 instances of Augmented STRINGS.
I might try predictive loading with size 1 - but it’s pointless when I know how little RAM I have on this one.
Not looking forward to another crash.
64 instances in 2 rackspaces is killer.
Then predictive load does not help as this controls how many rackspaces are loaded in memory.
Why do you need so many instances?
Is that just a stress test to show that this way you can crash your machine?
I was thinking the same thing. Why would you ever need 64 instances of Augmented Strings in a single rackspace? (or 2 of them!)
Then you have an undiscovered issue on your computer 
Gig Performer cannot crash your computer, but a driver or some system issue can.
yes - stress test.
this is not a lot at all - for some other plugins on iMac 2012 (ARP 2600 V3 classification worked perfectly.
this is also not a lot at all with Augmented STRINGS plugin for Mac Mini M4.
The purpose of these racks/variations is to audition the plugin presets way faster than through the plugin itself.
Also it’s a way to build from a starting point.
There are too many clicks to open the plugin, select the category, sort the plugin browser in alphabetical order, search for the plugin, load it. Then what? Drag the midi cable, drag the audio cables (saves a drag with shift).
Then when I need the next preset - same thing again right?
Open the plugin (quick replace saves some time and spares me the cables/wires) and do the whole thing over again. too many clicks.
These racks are thus time savers (on computers that can handle it)
Also since the widgets can be moved around - that means i can sort them in the order I want (although it would be nice to have more and easier control of the object blocks as I find the few options to align and distribute, center, to create a very slow workflow).
In short the racks are to become familiar with plugin presets and navigate through their categories (rackspaces) and presets within the categories (variations) quicker. Allows me to also combine sounds of the same category.
All that being said - stress test is the main purpose.
@jeffn1 I would never need to have that many instances in a live performance situation - certainly not instances of the same plugin.
@npudar Gig Performer crashed my computer due to asking for more RAM than my computer had to offer - when one does that - everything crashes, slows down, perhaps even turns off or restarts.
But then of course - who would use a computer like that other than for testing situations. 
I was trying that on my 4 GB laptop. I haven’t experienced any crashes; instead, the computer started moving stuff on the disk (virtual memory). Everything was so slow, but no crashes.
Honestly at first - as I was trying to wrap my head around what GP is and what it does and how to best use it, I considered (for a modular approach) creating
I did not come to any conclusion about what exactly the modular approach would be (that would save one from too many clicks and from too much wire dragging)
But at least for now - this stress testing method accomplishes a few purposes as mentioned in previous posts.
Ideally (for me) - one could load ALL plugins and all presets inside gig performer but that would require so much RAM and computing power - I am not sure such a device exists.
If someone has a better idea for a modular approach that saves on clicks and wire dragging - that would be fantastic.
@npudar - try opening the Augmented STRINGS rackspace I linked. Unless you have swap the size of like 60GB I don’t see how your 4GB won’t crash.
There is a user on the forum which made a very clever rackspace and sophisticated scripting.
Maybe you can take a look at his solution.
He is called @LeeHarvey.
But I am aware that I am torturing my computer with it. With 64GB RAM, everything works fine for me without paying much attention to performance.
Absolutely - it’s torture, and not for use live or anything like that.
My idea is to use it as a starter template.
Open it, remove everything I don’t need, and start my rackspaces buildup from there.
@LeeHarvey BTW I watched your video of your rackspace with the app on your phone - mindblowing.
I am not good at programming, but seeing what can be done with scripts makes me quite curious. I am just not sure I want to invest that much mental effort - given I don’t even yet have an idea how I can use gig performer for my needs.
rather i need to identify my needs more clearly.
for now - my needs were more about getting used to the presets of my plugins (removing factory presets I don’t need and keeping the ones that don’t bother my ear).
It is actually because of GP that I started caring about my plugins - cause up to now they have been just sitting in my computer. GP gave me some hope that they can actually be used live, and so I am experimenting now with those massive projects that are torturing computers. haha
Would probably end up navigating to one preset per rackspace for a modular approach. But those rackspaces would be imported in the gig file as needed, and maybe that would be a better template to start with? not sure. but certainly thinking about it quite a bit.
Yes, I think You are on the right track. That’s exactly what I and many others here have done. And over time, you can gradually improve, expand and adapt your default rackspace to suit your needs. For me, this was also a process that took several years, and I still have more ideas that I can implement when I have the time and inclination.
But the focus should always be on making music.
quick question - about protocol here in the community.
for posts that don’t require a solution - cause they are not a problem - do we leave the thread open for discussion? or do we choose an arbitrary solution (even though there wasn’t a problem) which would then close the thread?
Yes
It depends what you call a “preset”.
I would start off with the premise of one rackspace with every sound (a plugin with a particular patch) you need to use at the same time. (Maybe my term “sound” is the same as your term “preset”?)
Then, if you need to add another “sound” (a plugin with a particular patch), you could decide whether to create a new rackspace (especially if there is little overlap with an existing rackspace) or you could add the “sound” (a plugin with a particular patch) to the prior rackpsace and bypass it (and other plugins) that are not needed. You might have to use multiple midi in blocks and bypass some if you need different splits/key ranges.
Jeff
yes - that was what i thought at first.
just wanted to have these template gig files to better classify and audition my plugins.
then with that as a starting point, i will probably build my “real” gig files exactly as you mentioned.
when i say “preset” i am referring to a single preset within a plugin.
but i understand that a rackspace or variation can be more complex than just a single plugin preset.
it can be an entire “patch” with multiple layers, splits, complex midi routings, incorporating different controllers as well as different plugins with key parameters mapped to widgets to create variations based on need.