Duplicated rackspace that differs only in the preset loaded into a plugin

I have a rackspace that I duplicate all the time, changing only the preset that’s loaded into the main plugin. Obviously I can’t do this using variations, which all have to share the one plugin preset that was saved with the rackspace. But the proliferation of rackspaces with identical plugins and patch layouts can be problematic. Questions:

  1. Do each of these rackspaces take up additional memory, or are the patch layout and plugins shared in memory somehow?

  2. Having multiple “identical” rackspaces is fine when each one is for a separate song, but I have another gig file set up as a sort of demo for various plugins - for example, the 25 synth plugins in Arturia’s V Collection. I’ve ended up with several rackspaces for each plugin, giving me different classic preset examples for that plugin, and my gig file has gotten unwieldy with over 100 rackspaces. It would be nice if there was a way to at least group these rackspaces by plugin.

  3. When I play live, I’m glued to my MIDI keyboard, playing right hand and bass, working both pedals, and singing, so there’s no way I can interact with on-screen widgets, which is why the MacBook is not positioned next to me. My keyboard sends a program change to GigPerformer to select the rackspace for a song, and the keys, pedals, wheels and knobs send any needed controller message to G.P. So I haven’t needed to set up any widgets/panels on my rackspaces, making Variations kind of useless for my purposes. But if there was a way to learn everything about a plugin’s current state, and somehow save that in a Variation (I suppose that would require a widget for each setting?), then I would be able to use variations to effectively change the plugin’s preset. Is this a completely crazy idea?

1 Like

The state of a plugin is only stored in the rackspace and yes a widget mapped to every changed parameter would be a solutions - but you would need many widgets.

It’d be nice if there was an additional “invisible settings” feature in a Variation that wouldn’t require associated widgets (I don’t need the widgets). And then of course there would need to be a way to snapshot and store all the plugin’s settings, into the Variation. Like I said, crazy idea…

When you think of Omnisphere would need hundreds of widgets

Did you try scripting to send pc messages to a plugin to recall a preset - not recommended but could work.

You do not need scripting to send a Program Change message to a plugin.

All you need to do is attach a knob (or other widget) to a MIDI In block that is connected to your instrument plugin and select “PC” as the parameter. When you now move your knob - it will send PC messages 0-127 to all plugins attached to that MIDI In block.

Doing this (or other ways of reloading entire plugin states) will result in slow responses, will prevent you from using Patch Persist functionality and any other, rackspace specific, features, but it would work I guess.

2 Likes

Once you do that you would be at the mercy of the plugin, including any significant delay, while it restores stuff…the point of widgets and in particular variations is to support, well, variants, i.e, just a few settings (tweaks) that can be changed essentially instantly, without noticeable delays.

Yes, I get it. For settings tweaks that need to happen instantly, while playing a song for instance, Variations are the way to go. For other things, like my at-home demo gig file of the Arturia V Collection 7 synths, I’m setting up Variations that send a program change via a knob. In this case I don’t care about delays – this will save me a lot of duplicated effort and proliferation of rackspaces.

I’ve finally gotten the program changes working, after hours of research and testing (thanks @djogon for pointing me in the right direction). The Native Instruments plugins worked immediately with the PC knob widget. The Arturia plugins did not, and after trying everything I could think of and reading many articles and postings, I finally stumbled on this answer: I’ve been using the VST3 plugins, and apparently Arturia has not implemented the PC functionality in those versions. I switched to the VST versions of their plugins, and now the program changes are working fine. Go figure!

3 Likes

I totally second therealgps’ suggestion and share his discomfort. Duplicating racks feels rather unpractical to me and occupies more RAM. So having 16 racks just for the 16 Hammond presets I use in my gig is crazy.
Presets of the same instrument may differ quite a lot, and makes it very unpractical to manually map each of their changing parameters to a different widget so that it can be mapped to a new variation.
Also, I definitely don’t want to use program changes (as suggested as a workaround) to change presets of a plugin, and many newer plugins don’t allow that anyway.

A rack for me would better be considered as a set of instruments, fx and routings that I can modify to different variations (that’s what a rack is in the real world anyway). For instance:
variation 1: ON Hammond preset 1 / OFF rhodes
variation 2: ON Hammond preset 2 / OFF rhodes
variation 3: OFF Hammond / ON rhodes preset 1
etc

So, as a better workaround, I suggest that GP should provide a sort of meta-widget that maps to all the available parameters in an assigned plugin. This may also give the option to ignore some of the plugin’s parameters via checkboxes. This was something available in Brainspawn Forte and it was great!

If you use a plugin like say Kontakt - you could have it be your piano or your violin. Two completely different instruments with different parameters and, most importantly, completely different sound.

Loading a preset into a sample-based instrument could take a VERY long time depending on many factors and doing this live, while performing, is not only going to stop you from playing but will also, possibly, make your entire system unstable because plugins sometimes don’t handle loading like this well.

The only feasible way to switch plugin presets during your live performance is if your plugins that do this are not sample-based and can reasonably quickly and safely load a new preset.

This means that the memory consumption of these plugins is, most likely, minimal and RAM considerations are not really relevant. We may include such functionality at some point and allow users to switch a preset within a plugin while performing live, but please consider your rackspace as an INSTRUMENT rather than “include all kitchen sink” which many users coming from other applications try to do.

If you change your sound so much that it is sufficiently different - you should use a different rackspace for many reasons. Smooth transitions, ability to further tweak that sound by adding other plugins etc…

If you have your Hammond organ rackspace and if you drop all the drawbars as widgets - you should be able to create your variations for your Hammond sounds easily. You can do this VERY quickly by dragging one drawbar onto a panel and pressing number 9 before letting go and GP will insert a proper mix of white, brown, and black drawbars.

Please understand that MANY plugins that can safely switch to a different preset quickly do react to MIDI Program change messages which then means you do have this functionality. Just drop a knob onto a panel, connect it to the PC parameter of a MIDI Input block, and connect that block to the plugin you want. You now have an instant preset switcher - per variation.

Again - we understand that it is sometimes advantageous to load a plugin preset on-demand and we will see if there are ways to safely include this feature

Why is using more RAM a problem? Seriously…presumably you’re not planning on surfing the internet or reading emails during a performance.

Also, Gig Performer’s predictive loading feature can load/unload in the background to reduce memory requirements.

Hi @noou,

I am using Gig Performer since about 4 years and I never missed the feature of automatic preset switching of plugins in variations.
When you build your rackspaces with different variation with all the plugins/sounds you need and filter out note on events in the variation for plugin you do not need in the variation you are save.
No glitches like it could happen when you switch presets of a plugin.
Also a sample based Instrument could reload samples when you switch a presets and that load takes time, absolutely not glitch free.
Or you use different rackpsaces and predictive load.
This saves memory but you have patch persist, totally glitch free switch of sounds.

And a serious hunt from a longtime mainstahe and Gig Performer user: Do not try to implement the concept of another host to Gig Performer. The more you dive in and accept the concept behind Gig Performer, the more you will be impressed.

4 Likes

I really love gig performer. And I want to grasp all the wonders it have. Can you give more elaborate explanation on this topic?

And for my case, may be more about changing concept or way of performing from a keyboard (rompler) to gig performer. I am so used to rompler keyboard where I can freely change presets/patch on the fly without problem.

My stage is usually the church stage. In worship session, many times there will be unintentional change of situation. And I can suddenly change for example my sound for melody from violin to flute, or suddenly I feel slow rotary hammond will be more suitable than strings for background pad. It feels like I have thousands of patches at the ready whenever I need it.

I know getting gig performer rackspace to have gigantic choices of patch/plugin available anytime is ridiculous. So I try to take the most important/essential patches for me (plus 2 or 3 not so essential ones), and put all of them in one rackspace with widgets to control each patches.

May be you have suggestion as how to improve my setup, make it more efficient, and also how to change my mindset of performing to embrace more of greatness of gig performer.

OK, when I understand you want to change sounds on the fly.
Do you you need sounds in parallel and splits?

Only Bass in splits. Occasionally, I need to play the bass also (with left hand). But for other souds, I never do splits. Mostly parallel layers.

And I already installed GP 4 few days ago.

At the risk of rehashing some of the (very useful) material in this thread, here is my situation: I have a song list with ultimately 15 or so rackspaces. It felt like “going brute force” rather than an intelligent approach: I created new rackspaces for every song that had different sounds or plugins. That worked fine but the load time (upon start of GP4) had gone to north of 10 min. Not a joke. Then, the other night I experienced a hung computer (Win 10) during a gig. I had to reboot while the band was waiting and (literally) played 3 songs without keyboards. I have now made attempts to be a little bit more intelligent about it and successfully implemented a Global RS that holds my main instruments (Piano, Rhodes, Horns and Hammond - all through Kontakt). This brought the GP4 boot time down to about 3 minutes. I now still have to handle the less common instruments, which are an OBX, a MiniMoog and some Samples (via Kontakt again), so no large sample libraries. The plugins I use are the same but the presets are different for the songs. I was now hoping that I could create Local Variations (!) that would send MIDI Program Change messages to the various plugins when the Variations are being invoked. I have not gotten that to work (yet). I have run a lot of tests and trials and concluded that creating e.g. 15 rackspaces with the same plugs but different presets (which clearly works) still results in a loading time for 15 rackspaces - which once more adds notable loading time at boot time (not later!), even if no samples are involved. I was hoping that there would be a better way. My machine is reasonably fast, i7@2.8Ghz, 500GB SSD etc. Any advice will be much appreciated. Thanks in advance.

Do you know why?

Do you need instant access to every rackspace? If you don’t, or if you do but you follow a setlist, then predictive loading might help you.

Do you know for sure that your plugins accept program changes? Many don’t.

If you don’t need immediate switching, you could try the new (but experimental) GP Script function

 **LoadGPPreset(*p: Block*, *presetName: String* )**

It’s still marked as experimental but so far nobody has reported any issues with it.

To use this, click on the Save GP User Preset… in the plugin editor menu

screenshot_5227

and give the preset a name.

Do this for each of the presets you want.

Then create a rackspace script that looks something like this: (If you’re not familiar with GPScript, please take a look at the manual) – in this example, I have a synth with the GPScript handle “Legend”

Whenever the variation changes, we select the desired preset.

Obviously this can easily be extended but the concept works fine — the caveat is that you are now dependent on the plugin’s ability to load new state on the fly (make sure you test carefully) as well as any delays introduced by the plugin while changing its state — so you can’t leverage GP’s Patch Persist.

But it does work and should work with any well-implemented plugin – here’s a simple GIF demoing it

ChangingPresets

8 Likes

Cool beans!! This is useful!

Many thanks @dhj! Really appreciate your thorough response.

No, I don’t know why the computer hung up. It has happened on 2-3 occasions but it doesn’t happen a lot. It’s just really bad when it happens during a gig, as you can imagine.

I don’t need instant access to all rackspaces but the basic one (which is now the Global one) seems to be using a good portion of the overall load time and I need it to start the show. I have admittedly not tried the predictive loading yet. I will certainly give that a try.

I have done some research and it appears that the plugins accept PC commands. The ones I am using now are specifically:

  • AAS Ultra Analog VA-3
  • KV331 Synthmaster 2.9
  • Native Massive
  • Native FM8
  • SonicProjects OP-X II

There are a couple more that I COULD use if they solved the problem but currently am not:

  • u-he Diva
  • u-he Repro
  • Native Monarch
  • AIR Vacuum Pro

I will study the rest of your post in detail. I am somewhat familiar with GPScript and have programmed in my past so should be able to figure it out.

Once more, your response is incredibly useful and I really appreciate your time and effort.
Many thanks!