About to Move Ram Intensive Plug-ins to Global Rackspace

When I started with GP, I had no idea about being ram efficient, etc. Looking back at it, I had only rudimentary understanding of how Setlist mode works with rackspaces too.

My first objective was to replace my horn sections on my hardware synth (a weak point) with NI Session Horns. Shortly after I added Embertone Friedlander violin for solo violin parts.

Taking that simplest “path of least resistance”, I just created new rackspaces with Session Horns (and also Friedlander violin) for every song I used them in (I use setlist mode).

So, now I have like 16 rackspaces with Session Horns using the same exact settings and about 6 for the Friedlander Violin (these all use exactly the same settings).

I am also using about 100% ram on start up (I have 32 GB on my laptop). It slowly goes down to a bit above 50% after 10 minutes or so. (Could Windows know there are many duplicate files in ram and slowly release duplicates from ram? Could that explain why ram usage goes down? I have no idea. I am just speculating).

So, it is basically a “no brainer” to put Session Horns and Friedlander Violin the Global Rackspace and always access these instruments from there. I would think this should free up a lot of ram.

I learned that currently there is no simple MIDI out connection form local rackspaces to the Global Rackspace. (I am looking forward to the prospect of that in future versions of GP!).

So, there are apparently two ways I could approach this.

I could use OSC, as discussed in Nemanja’s blog post:

This seems like the simplest approach for me. I would just follow Nemanja’s blog.

But, I saw at least one post where someone had issues (apparently they were using a lot of ram too). So, I am trying to determine does the OSC method almost always work flawlessly? Or are there issues?

The other option (which, I guess I could try if I have an issue with the OSC method) is to put a midi input block in the Global Rackspace. Then I do not have to worry about sending midi to the Global Rackspace. But, considering my tech level, this is a bit more complicated for me. I would have set up widgets to block incoming midi note on messages when I am not using a local rackspace with those instruments. I am pretty comfortable I can figure this out, but it is not quite as straight forward as following Nemanja’s Blog for using OSC in this type of situation (his blog basically covers exactly what I want to do, I think).

So, I figured before I embark on this, I would try to get input. Go first for OSC method? Pros? Cons?

Thanks.

Jeff

I am not aware of issues

1 Like

Why not create one rackspace with variations and use the appropriate variation per song. That way you only have to load it once.

1 Like

Unless I’m missing something, you can just put a midi filter after the midi block and very easily filter out whatever you want. You can of course link a widget to it. You can also filter on the midi block itself. Nothing about this requires much skill.

1 Like

The downside of that approach is I might use it in rackspaces with different instruments. So, if I originally create a rackspace with it alone or it and some other instruments, I can’t use that along with different instruments in the rackspace.

So, it seems to me that the Global Rackspace is the perfect option in this situation. This way, I can use these instruments (in the Global Rackspace) with any regular rackpsace.

It is interesting. It seems like when the Global Rackspace was conceived, the main thought was that it would host effects. (Maybe this is why a Midi Out To Global Rackspace was not originally put in place?)

But, I think it can really help manage ram as a way to use ram intensive instruments that are used in many rackspaces.

Got it. You can go with the OSC thing you mentioned, or use the local rackspace to turn off and on your horns and violin in your global rackspace. Both methods work well, just depends on how you want to go about it.

1 Like

Re: “Would this midi block be in the regular rackspace or the Global Rackspace?”

Could you explain this a bit more? (I know this type of (non-OSC) approach is doable. It would just be more of learning curve for me.

I was just responding to this… Doesn’t really matter if in local or global RS.

Here’s how you would turn off/on the sounds from your global rackspace via your regular rackspaces. You can assign those widgets to the MIDI filter like @ztones mentioned or just use bypass.

It depends… But if you’re using your midi sounds in the global RS, you wouldn’t have the same midi block sending midi in there local RS right?

Yep, I would read through that to go that way.

But OSC seems a bit easier/more straight-forward to me. I would just follow Nemanja’s step-by-step instructions in the blog. Since it seems work fine for most users…and works for my purposes.

If I run into an issue, I can approach it the other way.

I appreciate the help/support!

Jeff

:slight_smile: am sorry, ztones, I am not sure what you mean by “midi sounds”.

There is no MIDI Out to Global Rackspace option right now in GP. So, the two work arounds are OSC, which seems to accomplish the same thing. How I view it, it basically creates (the equivalent of) a MIDI Out to the global rackspace

Or, I would connect Sessions Horns to the midi in block within the Global Rackspace.

I hope this makes sense…:slight_smile:

Right, you would put your midi in block in the global rackspace right where your session horns etc plugins are. So what I was asking you, is you would not have the same MIDI in block in the local rack space in those instances would you?

Correct, if I went that (non-OSC) route, I would not have a midi in block in my local rackspace connected to Sessions Horns.

Of course, I may well have midi in blocks connected to other instruments in that local rackspace.

Jeff

The way I do this is by handling all incoming MIDI events in the global rackspace, and then sending MIDI from there to the local Rackspace using the Local GP Port.

Hey, Solomon, I think my situation is simpler. I don’t need to send MIDI from the Global Rackspace back to the regular rackspace.

But, here is a pretty simple question:

I am assuming there is no problem sending some audio out from the Global Rackspace (e.g., Session Horns and/or Friedander Violin) and other audio sent out from the local rackspace. I would think that is common, but might as well throw it out there to confirm.

I think using local widgets to control midi note on/off in the global… or a step simpler, a hardware button on your keyboard that enables/disables the midi on notes in your global racksapce would be easier than OSC.

Yep, close call. If I could set up widgets with my eyes closed (like many of you can) it probably would.

But Nemanja’s blog post walks through the OSC route so clearly. Also, in my head I always figured I would send the midi to the Global Rackspace, so maybe that is part of it too. Luckily either way should work. Thx!

I am am putting two instruments (Session Horns and Friedlander Violin) (using OSC) how does that affect this?

What do you use to control which instrument is triggered from the local rackspace?

Do you need to put in place note blocking widget to avoid triggering the instrument you are not using?

[Sorry if dumb question…my specialty].

Jeff

It’s easy as 1,2, 3…

1- Make a widget in the Global Panel and in Advanced create a Global Parameter Assignment:

image

2- Now… map that widget to the block note on parameter of your midi in block:

3- in the local rackspace, create a similar widget and map it to the plugin “To Global Rackspace” and to the same Globaly Assigned Parameter:

Now they follow the same state so you can control the Global widget state from the local rackspace: