Understanding latency in GP

Picking this up from the end of the multicore discussion below

As the conversation had diverged from strictly addressing multicore interdependencies to talking about latency interdependencies

Thanks @djogon for that clarification. So actually the answer to my orginal question is that any latency introduced is applied to the entire audio stream. Thatā€™s useful to know, I will continue to carefully vet plugins and only use ones that donā€™t require any additional latency. Also really useful to know that those latencies are cumulative.

With regards to your first comment, however, I have thought about it and, respectfully, I donā€™t think thatā€™s the only option that makes sense for live use. Sure, I totally get that if you are setting up a phased speaker array in a large hall using GP you would want millisecond sync accuracy maintained throughout the setup. However, I suspect that the majority of users actually use GP to process their instruments live on stage. In that instance, Iā€™d personally prefer the flexibility. The absolute priority for me is that my primary instrument tone travels in and out of the computer with the lowest latency possible, ie the latency defined by my sound card. Anything that messes with that, from an musicianā€™s point of view, is a problem.

However, if I could split my signal chain, and run my signal through a delay on a second routing (a ā€˜sendā€™, effectively), delay set fully wet, then I would happily do that, as Iā€™m not playing to a click or synching with a beat, so a few extra milliseconds of predelay on a reverb or a delay is neither here nor there. Also, in the case of the exact delay timings you mention, I could just set my delay in milliseconds and subtract the extra latency the plugin is inducing, thus bringing the delay back into perfect sync. For the sake of a higher quality sound, those are all steps that would seem totally worthwhile to me.

As a comparison, I was running live rigs in Ableton before I came to GP. Ableton lacks a bunch of the really useful features of GP for live instumental performance (easy rig switching, routing flexibility, song linked settings and charts) but it has an interesting approach to latency management. Namely, it wasnā€™t til version 8 that they introduced latency compensation. Up until then, channels all calulated their own latency independently. That was great for live use, as you could do the kind of routings I was describing above, but obviously sucked for mixdowns as channels with heavier processing would end up being delayed relative to those with lighter processing. Theyā€™ve now introduced an option that latency compensates (ie delays all of the channels so everything is delayed to match the longest latency in the set), but itā€™s switchable. You can turn it off if you still want the old behaviour for live use.

Anyway, just my 2 cents worth on that. Thanks for clarifying. Iā€™ll continue with my current practice of careful latency management for now. Thanks for making great software.

1 Like

Iā€™d still simply try and play using those. You may find that you may not actually ā€œfeelā€ the additional few ms that some plugin introduces. Itā€™s a matter of how much and what kind of music/style you play. If it feels right - forget about the latency numbers.

As for the other stuff - weā€™re constantly improving GP to be the best host for live use and we will keep doing that. That includes some advanced processing stuff that leans on multicore options.

Thanks.

1 Like

Iā€™m not sure if itā€™s switched on by default, but youā€™re aware of the Display preference to show plugin latency when you hover over it in Wiring view?

2 Likes

This? when you hoover the plugins name title.
Screenshot 2021-06-27 at 11.54.21

Thanks, yeah, Iā€™ve spent a lot of time tinkering around with latency and different plugins in Ableton before coming to GP. Most of what I play is pretty percussive guitar styles (swing, blues, Rhumba, Folk), so I definitely find that keeping my instrumentā€™s latency down to 128 samples max is what feels correct for me. I take your point though. I wouldnā€™t care if I was playing swimmy pad sounds with long attacks, and, as previously mentioned, any additional latency on the wet delay or reverb sound probably wouldnā€™t feel wrong at all. Iā€™ll stick to my current methodology though for now. Thanks for clarifying how it all works. Really useful.

@keyman Yeah, thatā€™s the one.

@rank13 ah awesome! I didnā€™t know that was there. Many thanks for the tip. Thatā€™ll save time. Cheers

1 Like

Late Reply:

That was a question I would have asked if I hadnā€™t found the answers here.
When I upgraded to GP4 I ā€œfeltā€ a longer latency.Now I found the plugin, that added hereto quite a bit: The Voxengo Marvel GEQ which brings additional 8.6ms. As I had an additional one in the global RS I got 18.2ms just be theses EQ plugins. I will check out parametrical EQs, these seem to be really low in latency.
So thanks for the thread.

Greetings, HANS

1 Like