The upcoming "Global Rackspace" Feature.........Qs

Hello, since the other thread was deleted, and i do not want to derail the “your favorite new Feature thread”, here a own one, for global rackspace. querys and discussions.

What has been answered allready by the developers:
the “global rackspace” is good for 64 audio channels. ( i´d guess 64x stereo: edit: stupid me, ofcourse 64e channels in total)

  1. edit: clear now: 64 channels in total ! = 32 stereo, for both together, in and out

My main questions: (mainly point 1. )

  1. is the global rackspace able to use another CPU core vs. what the Gig uses, or will it be explicitly on the same CPU Core ?

  2. are we able to send audio forth and back as much as we want, just determed by the number of given audio ports, between “the single specific Rackspaces” and the “global rackspace” ?

64 audio channels means… 64 audio channels! A stereo pair needs 2 channels.
These channels comes from the local rackspace and can be sent back to the local rackspace again after being processed within the global rackspace. But they can directly come from the audio interface in the global rackspace, being processed and sent to the local rackspace. Or come from the local rackspace, being processed in the global rackspace and sent to the audio interface output.

But, damn, what are you planning to do with the global rackspace such that your immediate concern is the number of channels? 64 is huge for most of what I could imagine to do with the global rackspace! :face_with_monocle:

3 Likes

yes, for me too :wink:
but i wanted to see clear upfront.

But i can give an example:
i could come in with the Digitakt ( by overbridge) with 8x mono, which quite rapidly would turn to 8x stereo, which would allow for 2x “forth and back” in total ( local rackspace vs. global rackspace) . Thats still sufficient ofcourse !
but would eat up all 64 channels.
I just wanted to map my brain around :wink:

a point was the: how often could i go back and forth ? …to phrase it out that way.
but i guess thats clear now.

its not a concern ! i want to see clear upfront.
its a VERY powerful feature ! …i want to do some brainstorm upfront, to get an idea where things “could” go :wink:

since i still fight with CPU power, …and also with loading times.

you guys are taking me from the wrong side on this i think. its the second thread allready.
my backround is totally, that i´m coming from a “Sound designers” aspect or view ( hobby, but i´m on a pro level).
I don´t do what is needed, …i allways think in terms of “possible options” :wink: . my “play-patches” are then derived from there.
I´m coming from patching with a big if not huge modularsynth for the last 15 years, and do *same" now with VSTs, within the Box, thanks to gigperformer.
GP3 is the door for that !..so, i´m just trying to map my brain around for GP4 :wink:

i´m still in process to figure out the best ways to organise my patching with VST FX vs. VST instruments.
and GP4 will change here something.

There is no reason you couldn’t go back and forth if you wanted to. You’ll just have to use additional channels. You could send from the regular rackspace on channels 1-2 to the global one, then process something and send back to local rackspace on channels 1-2. Then you take that in the local rackspace , process and send back on channels 3-4, process in the global rackspace and send back on channels 3-4 and round and round we go :slight_smile: until you run out of channels.

As with everything in GP - the flexibility is there and it works just as if you used real cables to connect things.

6 Likes

yes, this was my point…but i get it now.
its supercool that this is possible !

one question remains open:
the CPU load of the global rackspace goes to the same CPU core as the whole Gig i suspect ?

Let’s please be a little patient - we can’t possibly answer all questions about all the new features in the forums. As I mentioned earlier - you can have multiple instances of GP running.
Running your FX on a separate core could and actually almost certainly would slow down the performance and introduce latency. So please - let’s leave the multiple cores discussion for another day. Thanks.

it was a simple question, and you answered it.

what does “unlisted” mean ?