Hi, I’m thinking about to build a GP based rig to use keyscape and a couple of vst synths like arturia collection and korg collection with a laptop and a studiologic SL88.
I cant find a way to save changing presets in keyscape with Variation feature.
I just want to know if is there a way to do this:
One rackspace with Keyscape and change patches without having to open vst and do it manually.
I know that must be possible but I’ve watches many videos and none explains that. Thanks in advance
I think the general advice of GP developers is “don’t do that”.Instead just use another instance of keyscape.
One reason is changing a preset on the fly may require substantial changes including loading samples into memory, which may impair stability.
Indeed - you also prevent the ability to do instant switching
It can be done using GP Script but it’s generally a terrible idea - don’t try to fight the GP paradigm. Just instantiate a new instance of Keyscape with the appropriate sound in each rackspce.
Ok. Thanks. It doesnt look like a friendly idea with memory management but I will give it a try.
In general, let Gig Performer worry about that 
If you really get into a bind you can leverage GP’s predictive loading feature.
Also, you can save memory by reusing the same plugin/sound in multiple songs without adding another instance. There are posts discussing this. (As well as other strategies to manage ram use).
You could create a rackspace and map widgets to a global instance of Keyscape - but this might be more trouble than it’s worth. You’ll need multiple rackspaces to cover Rhodes or C7 etc. You’ll need to map every control to a widget or you’ll run into problems switching between pianos thanks to variations of the controls exposed by Keyscape. I gave up on this approach.. it wasn’t worth it. In the end, I used the one rackspace/Keyscape approach and let Gigperformer do it’s thing. Works well and lets me focus on the playing
Other options are to use physically modeled plugins for keyboard sounds, like Lounge Lizard, Piantoteq, and IK Media’s B-3X. (They use far less ram).
I use Pianoteq and lounge lizard but I thought that B3 was sampled
IK’s B-3X uses physical modelling, and it’s an incredible CPU hog. On a modern system like silicon macs not really an issue, but older machines might have some hiccups. A great option with hybrid approach (some attack samples but mostly modelling): Acoustic Samples B-5 V3. Much lighter on resources than B-3X, even though IKs Leslie modelling is superior IMHO. UADs Waterfall is also a great, great option.
Only widely used sample based option I now is the Vintage Organs from Native Instruments. It was a huge disappointment back in the day when they released it as a follower to their B4 II, it really sucks compared to most options.
I know that, but is uses a lot of samples and does not stream from disk.
Most CPU is consumed when you use the inbuilt EQ and compressor.
I am using it on a Mac Intel 2018 Pro and I can live with the CPU usage.
I’m pretty sure IK Multimedia’s B3-X is physically modeled, not sampled.
I am sure that also samples are needed.
I knew it was a CPU hog but I guess I forgot it was a physical model. I wonder why it is so CPU intensive compared to other physically modeled organs (Blue3, VB3, etc)
I think the Leslie Emulation and their inbuilt EQ is the culprit
Very likely, I also have their separate Leslie plugin and it’s quite heavy just on its own. Modelling just the basic sound of the tonewheels is relatively simple compared to that (I think even some decades older hardware clonewheels do a pretty good job at that before you add their terrible leslie sim).
The quality of the leslie modelling is what sets IK and UADs Waterfall apart from the competition. This is coming from someone who’s spent lots of time with a real leslie cabinet, the only characteristic missing from all the models is the sheer power of the physical cabinet making the whole room resonate, but especially on a recording or a bigger live venue where the PA sound is what the audience will be listening, nobody can tell the difference between a genuine miked leslie and a great model (apart from the musicians standing next to the cabinet). That’s how far the modelling has come.
Back when the Neo Ventilator pedal came out I remember reading a SOS review where the writer was touring with a real leslie as the “stage monitor” while the Ventilator signal was what the FOH was receiving. The lenghts some people will go for just that physical sensation 
I think the OP’s question comes from a slightly different place. Back in the day when I was starting with GP and building my first live rig, I had the wrong assumption that I could have different patches as variations, f. ex. one rackspace with Keyscape and different variations of that rackspace handling C7, Rhodes, Wurly, Vintage Vibe etc. Hey, they do use the same wiring, don’t they?
Once I understood that variations affect widget values only, it all started to make sense, i.e. rackspace per patch.
I read the original post as the OP having the very same misconception that I had.
Same thoughts here.
It seems in fact that a lot of (new) users just don’t grasp the actual meaning of “Variations”.
I’ve no idea of how that situation could be improved… maybe if there was a video with a really, really explicit and clear explanation of what variations are and what not (specifically the “what not” seems to be even more important in my opinion)!
To me it helped/helps to understand variations and widgets in terms of the constraints of computers.
Basically the GP developers want user to be able to switch sounds instaneously.
Variations are basically a way of using the same rackspace with as many changes as you want performed by widgets.
But, stability and fast changes to variations would be undermined if you changed a sound where a lot of samples had to load (or maybe even if every parameter in a soft synth changed).
So, widgets and variations allow you to change a lot of different parameters, but not ones (like loading samples) that would noticeably slow down changes or possibly cause instability to the setup.