It appears that you can indeed use the FX loop without extra latency. Simply use separate send and return blocks to lower your dry signal latency by about 1,85 ms. This actually makes sense, since you wouldn’t want to add latency if you used the returns as another pair of inputs or if you used the send as an output from the grid.
It appears that there is no extra latency when using separate send and return blocks. I hope no one will be confused by the comb filtering when using the QC like this, but I’m satisfied. You can compensate for the latency by delaying the dry signal by about 1,85 ms, by using an empty IR loader block for example. I suppose that solves this request.
EDIT: Changed the thread title to make the request clearer.
Request:
-add a switch or global setting to choose whether or not the fx loop latency is compensated by delaying the dry signal
-overall latency of the dry signal can be reduced by a relatively large amount
-when using 100% wet reverbs or delay effects in the loop, there will be no issue with having less latency
-You can still choose to have more latency if you want to, there is no downside other than having one more option.
-You can have the latency compensation on by default, so no one will be confused
Original request:
Currently, when you insert an FX loop block into a preset, the entire signal appears to have added latency. The FX loop should only add latency to the signal that’s actually going through the loop. Apparently, this is how at least Helix/HX devices work. This would improve latency considerably by not adding the FX loop latency (~1,8 ms) to the dry signal when using the FX loop in certain situations, e.g. when running 100% wet delays or reverbs mixed with the dry signal.
How to test this: insert an FX loop block in series with only a patch cable plugged into the loop. Adjust the mix parameter in the FX loop → the sound doesn’t change. There should be a comb filtering effect that changes the tone noticeably if the latency differed between the signals. This also happens for some reason when the FX loop is routed in parallel. If you add a device that does an A/D/A conversion to the signal but doesn’t otherwise process the sound, you will notice the comb filtering when you change the mix amount.
You could also have a latency compensation switch if you wanted the extra latency for some reason.
If you have 100% wet effects, there will be no phase issues. If you want the latency, you can just have an fx loop in series with the mix at 100%. There is no downside to this, especially if it’s switchable.
The downside IS if it’s not switchable. Someone may want to use it to blend with an external distortion/fuzz, in which case the latency is very important.
The issue is that there’s added latency when it’s not needed in all cases. I would rather have the choice of having lower latency when using the fx loop. There was a HUGE thread here complaining about latency before it was improved. This is another chance to lower latency in many use cases.
Let’s say that you have a 100% wet delay or reverb in the loop, which is what I often have. There will be no difference in sound whether or not the latency is added to the internal dry signal. The only difference is that there’s an extra ~1,8 ms of latency needlessly added to the dry signal.
So the delay repeats would always be slightly off because of the latency, and the pre delay you dial in for the reverb would be wrong because you’d have to adjust for the latency time as well.
Doesn’t seem worth even it for neural to do if the latency for the loop is only 1.8 ms. That’s basically negligible. More latency is introduced just from a boss pitch shifter pedal being in the chain.
I would argue that it is worth it to reduce latency by more than 30% in many cases. If it’s switchable, you could choose to have the latency if you want to. It’s also trivial to reduce delay time by 2 ms if you truly were worried about such a small added delay in a delay or reverb. A delay being 2 ms off is practically nothing, when were talking about delay times usually in excess of 300 ms. The latency of the dry signal in the QC is like 3,1 ms in a basic patch, so 2 ms is a relatively large increase.
Latency adds up. It’s your base latency PLUS 1,8 ms, which can bring the overall latency up to perceivable levels. Adding a single switchable option is not really complicating an already complicated device.
Actually, it appears that there is no extra latency when using separate send and return blocks. I hope no one will be confused by the comb filtering when using the QC like this, but I’m satisfied. You can compensate for the latency by delaying the dry signal by 1,85 ms, by using an empty IR loader block for example. I suppose that solves this request.