Why Latency Compensation Must Be Adjusted Between Projects

When following a master clock from a DAW, the Latency Compensation feature in CLOCKstep:MULTI will allow you to align the timing of an external sequencer if a noticeable latency has developed.

Even though this compensation is easy to set, it may also help you to understand how the feature works behind the scenes, because everything is not as simple as it appears.

This is a representation of real-time latency that occurs between the Source Clock and the Target result:

The type of clock widely used for music sequencing is tempo based. Here we are demonstrating a clock with a sync rate of 24 PPQN running at 120 BPM, which makes the expected interval between each pulse roughly 20.8ms.

The adjustment seems simple at first. The clock pulses must be negatively offset by the device that's following the clock. In this case it has been determined that the amount of negative offset required is 6ms for real-time monitoring of both signals:

But in thinking it through, how will that actually work? How can a device register a clock pulse that is 6ms earlier than the Source clock that it's following?

The answer is: It can't. This requires a different approach. If it can't create pulses that are 6ms earlier than the Source clock itself, then what about making them even later using a positive offset?:

We know that the expected interval between pulses is 20.8ms and the latency is 6ms, so a device should be able to increase the latency even more by 14.8ms, and in doing so, the Target's time slices will align with the Source:

Although the pulses are now aligned, notice that the count of the pulses in the Target have actually changed. What was pulse #2 in the Source is actually pulse #1 in the Target.

This can be a problem if you expect all of your devices to start at the same time automatically. The Target device that has latency compensation will start 1 pulse later than any other device controlled by the Source Clock.

What's needed is a Pre-Roll: A period of time where the clock is running before the devices start their sequences. This will allow time for the device that's coordinating the latency adjustment to factor in the 1 "missing" pulse:

So far, we've seen how external Latency Compensation is calculated and used at 120 BPM, but what happens if the tempo being used changes? What would 140 BPM do to the Latency Compensation adjustment required?:

We can see that the expected interval between pulses is now 17.8ms, down from 20.8, and although the amount of latency is the same as it was before at 6ms, this change in BPM has created a different positive offset requirement: 11.8ms.

This is why, for each project using a different Tempo, Latency Compensation has to be reset. The latency itself doesn't change, but the calculation required to produce a positive offset and change it into a negative offset does.