Going down this path of exploration is certainly good and useful, but having done this myself I’ll point out a few things that may save you some head scratching. And maybe one thing about the GP terminology.
As dhj noted above, a Rackspace is the thing you see on the wiring diagram where you add VSTs, and there are corresponding panels where you place your widgets. A rackspace has one or more variations, where the only difference between variations is what the widgets are set to.
A song is made up of one or more songparts, and a songpart is just a reference to a rackspace variation. There are a few additional things to songparts, but for the most part the whole point of songs and songparts is just to have a song-oriented way to point to different rackspaces.
Any time you are placing VSTs you are placing them in a rackspace, period. You can’t place a VST in a song or delete a VST from a song. The song is just a pointer to the rackspace.
Putting that “language” stuff aside, what you’re seeing with the different VSTs is generally “real” with regard to CPU, but not necessarily “real” when it comes to RAM.
Very generally speaking, a “modeled” instrument is going to use a lot less RAM and more CPU, where a sampled instrument will use a lot more RAM and in most cases less CPU.
The Arturia B3 and IK B3-X are modeled, as is Blue 3 (which you didn’t mention but is very popular). The Native Instruments B3 is sample based (as far as I know, I don’t use it).
The various B3s all tend to come with a bunch of effects these days (reverb, amp sims, Leslie sims, etc.) and those will all take additional CPU. I don’t know how Native Instruments handles that.
When you run GP it is generally going to put all of the audio processing on a single core of your processor. If you look at the performance in Task Manager you’re going to want to view all the different cores individually to understand what’s really going on.
If you run multiple instances of GP, generally speaking each instance will have its audio processing on a different core. So you can absolutely get more VSTs working if you use multiple instances. However it’s not simply additive. I spent a fair amount of time testing that out a few times just because I felt like it. I did most of my testing with “well behaved” VSTs, which at the time was mostly Pianoteq and some Melda FX.
By “well behaved” I mean that they took almost no CPU when not playing any notes, and were not ridiculous CPU hogs when doing “normal” things. At the time I was doing that testing I could get 3 instances of Pianoteq in one GP instance without glitching at 48kHz, 96 samples. If I went to 4 Pianoteqs I would get crackling from time to time.
If I put two instances of Pianoteq in each of 3 different instances of GP I could get six instances of Pianoteq without glitching if I disabled “virtual cores”. If I left virtual cores on I could only reliably get 5 instances as I recall.
The only point of running those tests for me was curiosity. The point was to see how linearly capacity would scale with instances. I was wondering I’d be able to run, for example, 8 instances of GP with each having three Pianoteqs playing at the same time, or 24 Pianoteqs total. It was nowhere near that. It was five vs. three, so by going from one instance of GP to three instances I got less than double the Pianoteq capacity. Going to four or five instances of GP didn’t seem to add much for me on that processor at that time.
In task manager I could see which core each instance was running on. I’m oversimplifying a bit, because GP will run different threads on different cores. The UI, for example, generally won’t run on the same core as the audio engine if you’re running one GP instance. If you run more instances of GP you may end up with the UI process of one on the same core as the audio thread of another. At least at that time in my particular case. More instances means more likelihood that the UI of one overlaps with the audio of another on the same core.
Coming back to RAM, Windows does its own thing with RAM.
Just because Windows shows your RAM going up doesn’t mean its going to stay up, and just because it reads low now doesn’t mean its going to read low later. At least that’s my experience. But if you’re not running out of RAM, it doesn’t really matter. If you are running out of RAM then you’re not going to avoid that problem using multiple instances. I expect multiple instances will always consume more RAM than using a single instance, all else equal.
I suspect in your test where you added then deleted VSTs you were seeing oddities in how Windows manages and reports RAM use rather than a “memory leak.” I certainly won’t rule out the possibility that either GP or a VST has a bug where RAM isn’t being released properly, but that wouldn’t be my base assumption given what I’ve observed of Windows reporting in Task Manager in general.