Zero reported latency, and what it does not mean

Every plug-in tells the host how many samples it holds the signal up before anything comes out the other side. Lookahead limiters hold up a few milliseconds so they can see a peak coming. Linear-phase equalisers hold up rather more. Oversampled processes hold up whatever their filters cost.

The host takes that number and delays every other track by the same amount, so nothing drifts out of alignment. That is delay compensation, and the number driving it is a report rather than a setting. The plug-in states it; the host acts on it.

The obvious objection is that a delay is made of delay. But the wet signal being late is the effect, not latency: it is what you asked for, and moving the whole track to compensate for it would undo the thing you wanted.

What matters for compensation is whether the plug-in holds the signal up before producing any output at all. Tempo Delay does not. What arrives in a block leaves in that block, and it reports 0 samples.

A plug-in that reports latency makes the host shift things. In a well-behaved session that is invisible and correct. It stops being invisible on parallel paths — a send running alongside the dry signal, a duplicated track, a bus feeding another bus — where the compensation has to be right on both branches for the two to stay in phase.

Anything reporting zero sidesteps that question entirely. It can go on a send, in parallel with the dry, or in the middle of a chain, and nothing moves because of it.

It says nothing about the rest of your chain. Put a lookahead limiter after it and that limiter still reports its own latency and the host still compensates for that.

It is also not a statement about processing cost. Latency and CPU are unrelated: a plug-in can be expensive and report zero, or cheap and report thousands of samples. It is one number, about one plug-in, and here it is zero.