Global Rackspace. Sending Midi to Virtual Instruments

This question was touched on in another unrelated post so I thought it deserved its own Topic.

I just upgraded GP4 and was very excited about the Global Rackspace. Specifically, I was hoping to share Virtual Instruments–not effects. It turns out, to the best of my searching and reading, that sending MIDI to the Global Rackspace isn’t supported.

My use case is that I have about 30 RackSpaces–most of them have identical instances of HALion as one-third of each song. I typically have different sounds on my other two controllers. So, because I have so much redundancy, it takes just over two minutes to load my Gig. This feels like an eternity when the rest of the band is waiting.

I saw one person here with a workaround that I didn’t quite understand using mido filters, but generally, I don’t think what I am searching for is possible at this point.

Two Questions:

  1. is there any way in GP4 to minimize the redundancy that I have? I use Program Change on one controller to switch all three controllers and move between songs, so I don’t think Variations is the answer.
  2. Is “Sending MIDI to Global Rackspace” on the roadmap? If not, where is the best place to make a feature request?

Thanks :slight_smile:

Why not just use midi in in the global rackspace?

Are you loading a gig file after you told the audience what song to play?

Yes, it is.

1 Like

I was looking for Midi in global rackspace. I didn’t see it. Maybe I was just looking for midi out from the local rackspace. I’ll take another look.

Just include MIDI In it like any other plugin

Often, when there are multiple bands performing on a show, there is a rush between acts. The two minutes is a long time when everyone else is using back line and are already waiting for me to set up my rig. Seems short but is a very long time in that situation.

Use predictive load and you are faster in loading

1 Like

I’m not sure we’re talking about the same thing. I have no problem between songs. I’m just trying to avoid loading 30 identical instances of the same virtual instruments by loading it once in the Global Rackspace. This will cut initial load time down significantly.

With predictive load for example set to 3 the first 3 rackspaces are loaded and then te red is fast pre loaded.
When you switch through the rackspaces the next needed is loaded and the oldest is released.
So load your gig in a partial loading time than you have now.
That all is well documented.

And by the way, I think loading 30 instances of a plugin in the global rackspaces is not really faster than loading simple rackspaces with all the same plugin.

Thanks for the clarification. I didn’t know you could load an initial state using predictive load. I tried it in a different way some time ago when I was learning.

And then you bring up something else I don’t understand. The reason I think the global rackspace is the right way is because they all have the same patches loaded. I use three controllers. The bottom one is usually the same patches loaded. So this is the redundant one. The other two are typically different per song. So I would, I think, load redundant HALion instruments—each with the same patches loaded for my bottom controller. (But I’m probably missing something else again).

I am strugling with the (pretty) similar issue.

If it is The Same (exactly the same instance of Halion, with same programs on same channels and same MIDI split/layer functions) - you can make it in Global Rackspace (open Halion while in Global, load programs into it, setup Midi Input (as in regular Rackspace) and audio - just as you are making the regular Rackspace - but just for Halion.

Then - in the regular rackspaces, just open Internal Plugins > Global Processing > From Global Rackspace - and that’s it - you are playing your bottom keyboard with Halion setup, and making the rest of Rackspace for particular needs.

I hope it is on the way for your needs…

But generally - there is a lot of empty space for clarifying the way the Global works, as well as different options we have (or should have).

For instance - in the panel of the rackspace, you can choose the Mapping on the Plugin level as “From Global Rackspace”, but on the Parameter level there are a lots of “not assigned” values? How can we assign the value for particular need?

We have the opportunity to use Panels in Global Rackspace - but I didn’t find the way how can I assign those for speciffic regular Rackspace that uses the Global one?

tnx, and sorry for the long post :slight_smile:

1 Like

The question I have is my wife ties into my GP4 and I have three other keyboards and drum pads on the Arturia. She uses an acoustic grand piano sound on a lot of songs but sometimes she has combination sounds and even strings or whatever is needed for the particular song. If I put the midi coming from her Disklavier to the Keyscape piano in the global rack, how do I give her a different sound in the regular backspaces? The Disklavier is always going to be playing Keyscape piano. If I just put a volume fader to not hear the global rack space both would still be playing eating up the CPU.

It would be great to have a global to midi out connection in the main rackspace so the global midi in to Keyscape could just sit there and be ready for the songs that use it but when I give her a other sounds the virtual synth could remain in the main rackspace and not play the global rackspace and eat up CPU.

I do not understand, plugins in global rackspace and local rackspace can be played at the same time.

1 Like

Then bypass the global rackspace plugin. You can do it securely with a Scriptlet:

I don’t want them to play at the same time. When she plays a sound other than piano I don’t want the piano in the global rackspace to play.

Let’s call your wife’s keyboard controller WifeKeys. Let’s say she often plays a Kontakt piano, which we’ll put in the Global Rackspace, and sometimes other things, which we’ll put in the regular rackspaces.

Not really a problem.

Add a button widget in the global rackspace. Link that widget to Kontakt, and in the parameter select, choose Bypass. Now this widget will bypass Kontakt when active, meaning it won’t make sound and won’t use CPU.

You’ll want to control whether this is active from your regular rackspaces. To do that, go back into Edit mode on the global rackspace, select the widget, go to the Advanced tab, and choose a slot on the Global Parameter Assignment dropdown on the lower right of the widget assignments area. Let’s say you pick “Param 10”.

Now go to a regular rackspace. You will need to do this for all the regular rackspaces where you want to be able to mute that global Kontakt instance.

First, on the wiring page make sure you add the plugin “From Global Rackspace”. Now go back to the panel and add a button widget that will bypass Kontakt in the Global rackspace. Select the widget, and in the plugin mapping (lower right) select plugin “From Global Rackspace”. Then for the parameter you’ll see a long list of parameter that mostly say (not assigned). But the 10th one down will have a name and it’ll be something like “Bypass Plugin Kontakt”. (It’ll be the 10th one down if you selected Param 10 in that prior paragraph.)

Hope that all makes sense.

With that done, you can bypass that global instance of Kontakt in any rackspace where you add that widget. When I do such things, I put that widget in every rackspace, and when I save every rackspace it will remember what the state of that bypass switch is.

I do this with four or five commonly used VSTs that I use for secondary keyboard or bass sounds. I throw them all in the global rackspace and then have those bypass buttons in each regular rackspace so I can control which of the VSTs in the global rackspace is actually playing.

[PS - as David-san referenced just above, this approach comes with the caveat that it will immediately silence that Kontakt instance if you switch to a rack where it’s silenced. To get around that requires the scripting solutions he referenced.]

3 Likes

Nice one! It may take me a minute to sort it out, but I get it.

Thanks!!

That’s very kind of you — I wouldn’t have used that variable name myself :slight_smile:

Happy wife happy life :wink: