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.