Hi everyone. I’m wondering if there is any resource pool on the subject of how latency is managed in GP. I’m hoping to use GP for some FOH work (individual channels as well as group and mix buss processing) and i want to be confident when it comes to managing timing alignment and mitigating latency issues. How automatic/manual is latency management in GP? Does routing between rackspaces effect any automatic latency compensation? And so on…
If the team at GP are listening, a youtube video breaking it all down would be an amazing resource. Can any of you guys point me in the right direction to some resources? Or do you have the information I need yourselves? Thank you very much and I’m excited to be on board
GP has automatic latency compensation in each rackspace.
Connected wires gathered into a block are compensated to the highest latency value calculated from each wire.
Each rackspace has its own calculations starting from zero.
Note that adding more latency control is already high on our list.
So we should feel quite confident leaving latency management up to GP within a rackspace but I have one remaining question about how that compensation happens within a rackspace: If a rackspace fans out into a fairly complex tree of connections but ultimately all consolidate into 1 mixer module at the end of the connection tree, would GP compensate for the entire connection tree at the mixer module or would it only compensate for the latency produced by the modules 1 step up in the chain alone, leaving possible latency mismatches further up within the tree? (If this isn’t clear, I could try produce a visual representation of what i mean here.)
In addition, could you elaborate on how to go about, at least manually, mitigating for latency when connecting between rackspaces? As a simple example: say we have 2 rack spaces, each having a different total chain latency by the end of the processing each rackspace is carrying out. How should we go about sending both to the global rackspace where they may be summed together and therefore would need some form of latency consolidation?
I think the above two scenarios are simplified examples that, if explained, would help us understand the principles very well.
When sending from a local rackspace to the global rackspace, then the global rackspace ignores the total calculated latency,
In example above, ‘From Rackspace’ block at the global rackspace is treated with latency 0, although the calculated 257 in the local racskpace.
In such a case, will the mixer module latency = max(Plugin 1, Plugin 3) = 4ms or would it be latency = max(Plugin 1, Plugin 2+3) = 7ms?
ie will the mixer align the full signal chain’s latency or just compare the inputs it is seeing directly (Plugin 1 and Plugin 3)?
With respect to local rackspaces and @pianopaul’s comment, should I expect that GP will allow for multiple local rackspaces to process audio simultaneously any time soon or should I just forget this hope?
@pianopaul is correct, the latency will be 7ms and only single local rackspace is active at a time.
I’ll also mention (although it should be obvious) that Plugin 1 will be compensated (delayed) with the extra 5ms to be aligned with the 7ms of the other tree connection.
