Global Rackspace. Sending Midi to Virtual Instruments

As a follow up to that “bypass” global widget approach, it occurs to me you could also accomplish the same thing by blocking “Note on” effects with that widget in the global rackspace rather than Bypassing the Kontakt.

The benefit of blocking note on events instead of bypassing the plugin is you shouldn’t have to worry about abrupt sound cutoffs. The potential downside is Kontakt might still be burning CPU even if it’s not receiving note on events. Not sure, I don’t use Kontakt much.

Kontakt is very good in not consuming cpu when not played.

And if you want the best of both solutions… tadaaaa… the “plugin persist” Scriptlet :stuck_out_tongue_winking_eye:

3 Likes

That’s something I missed in manual (or there isn’t any mention of it?)

tnx a million for that one :smiley:

Even easier (for Piano sustain patch persist situations) - put MIDI Filter between MIDI In Block and Plugin, with Block All and allow CC64 (sustain) - and make it as Bypass Plugin “master” in Global - you have the continuous sound when holding Sustain on Piano sound…

There is!

2 Likes

tnx dhj - I’ve missed it :vulcan_salute:t2:

There is nothing particular to do regarding « patch persist » which always works fine I think. The « plugin persist » Scriptlet is supposed to implement something similar for switching between variations and simply delay the plugin bypass operation when it is no more risky to do it and without using additional plugin blocks.

Trying to understand this… Let’s take an extreme case and say I have 6 VSTS defined in my global rackspace. From piano to organ to horns… etc. etc. – all different vsts. Now let’s say I want to include the global rackspace in most of my rackspaces. Can I (via the panel editor and toggle switches) mute VSTS? In other words – have the global rackspace included – but only have the piano VST active and the other VSTs muted via a volume knob or toggle swtich in the song rack space? Can knobs and switches in the song rackspace – have granularity down to the VST in the global rackspace?

Try this:
https://gigperformer.com/docs/GP4UserManual/how-to-control-widgets-from-global-in-regular.html

Yes. There are a couple different ways to approach what you want to do, each with different tradeoffs.

In all cases you’ll put your 6 VSTs in the Global Rackspace and by definition those will be available to any Rackspace in that Gigfile.

How you want to control whether you hear them or not is where the tradeoffs come in. Without getting into scripting, there are three different ways I can think of to control whether or not they are each making sounds:

  • Have a bypass switch for each of them, so you can toggle them each on and off individually
  • Have a midi filter in front of each of them, so you can stop note-on events from reaching them when you don’t want them to play
  • Have them all playing all the time, but send them into a volume mixer where you can control how much of each of them you hear all the time

You can combine that “volume control” option with the bypass or filter option as well if you want.

The link jpt posted above describes how to link controls in the global rackspace to your non-global rackspaces.

The tradeoff of the different approaches is that when you do the “bypass” approach the sounds will cut off immediately when you switch racks. If you do the “filter note-on” approach your notes will sustain, but your “inactive” VSTs are still enabled so may drain CPU resources even though they won’t receive “note on” events. Some VSTs can be resource hogs even when they’re silent, although most of the one’s I use are not.

That final option of just controlling the volume is useful if you do a lot of different layering, but clearly if you have VSTs playing that you just mute in a volume mixer then you’re draining CPU for nothing. Again, depends a lot on the VSTs whether this is an issue or not.

1 Like

I’d just like to point out that you’d not “include” the global rackspace. It’s there at all times - nothing to include.

What you can include or not is a local widget that controls some other widget in the global rackspace so you can have variations and song part overrides for example.

1 Like

Thank you, danigell. Your instructions were perfect and I set up a Global instance of HALion. I may need to rethink my Gig settings to take advantage of this.

Thank you Vindes and Jpt. Your explanations and manual link really helped. I get the concept and it works well. I’ve used your suggestion of incorporating toggle switches in my “current” rack space to my global rack space to turn vsts on/off, transpose, and turn midi channels on/off. Guess I should have RTFM. :slight_smile: as you know this global rack space is great for things like pianos—- where I always want the same patch. Now I am wondering if it is possible to send a patch change to a vst in the global rack space. So… from a current rack space, can I send a patch change to my lounge lizard vst as an example? If this not a good practice, I can take that— and I’ll just put lounge lizard in rackspaces that I need. I use lounge lizard in quite a few rack spaces, but rarely the same patch. Thanks!

Why would you do this as opposed to putting them in individual rackspaces?

Not with @David-san 's plugin persist scriptlet. It’s super handy!

1 Like

It only works between variations, not between Rackspaces…

Oh right!

Between rackspace you have the real GP Patch Persist.

1 Like

I’m inferring then that it is best practice when having multiple VSTs in the global rackspace, to bypass the VSTs that are NOT in use when the global rackspace is included in a rackspace — in order to save CPU. Is that correct?