So a bit of a technical, “how does it work under the hood”, question.
If I use a particular plug-in, let’s say the Arturia Jupiter 8, and I use it on 20 different rack spaces, does GP load 20 instances of it? Or is it smart enough to know that it’s the same thing so it only loads one and then just changes parameters when I switch rackspaces?
A shared library essentially has several parts — code and data. Assuming the code is not writable (which is normal these days) then the code part can be shared so only needs to be loaded once, no matter how many applications use it. The instance data has to be loaded separately for each instance because the data (generated sound!) is obviously going to be different for each instance.
This is generally handled by the operating system.
I think it pretty much reloads it. There have been some threads on this topic.
In terms of ram, this is more of a concern with heavy sample-based instruments. Some strategies to help control ram use could be to put often used heavy ram-based instruments (where you are using the same “sound”) in the Global Rackspace or reuse local rackspaces (and bypass non-used plugins using widgets/variations).
[I once suggested an option to “freeze” a plugin so you can reuse it in any local rackspace (without making changes to the plugin itself) without having to re-load the instrument. It still makes sense to me, but obviously the difficulties entailed in re-coding are probably substantial (of which, I admit ignorance) and putting the instrument in the Global Rackspace achieves a similar effect.]
It doesn’t reload it physically — the whole point of shared libraries is that the code is shared
This is a basic function of any OS that supports a modern virtual memory model. It might “appear” at different virtual addresses but in physical RAM, it’s only there once.