Issue syncing a sequencer with Logic/BPM reporting

I am working on a basic step sequencer and discovered an issue with Logic (macOS) and possibly other hosts (AUM on iOS).
If the BPM has four decimal digits, the plugin gets the first three digits only.
For example, if you set Logic to 120.1234, the plugin gets 120.1230.
In Reaper, instead, the fourth digit is reported correctly.

So apparently, this issue might happen in other hosts too, like AUM on iOS with Ableton Link, but it’s just a suspicion based on a few reports from our customers. I need to double check.

So, the end result is that the sequencer drifts if the BPM has more than 3 digits and I have no idea how to work around that. Any thoughts?

1 Like

Are the results of getPpqPosition and getPpqPositionOfLastBarStart accurate? If so, can you use those values so that each audio block starts at the correct time relative to the host timeline?

Yes, they seem accurate. I’ll see if I can’t re-adapt everything to use those instead of the BPM. Very annoying.

On getPpqPositionOfLastBarStart:

Note - this value may be unavailable on some hosts, e.g. Pro-Tools.

Is that true?

https://docs.juce.com/master/classAudioPlayHead_1_1PositionInfo.html#ae3c5996d291870e4713d1818f636a4a9

Might be easier to have it fixed in logic ?
Especially as very few users will actually have four digit after the comma
and the drift is probably not very big or only after several minutes ?

That’s true, but it’s still not ideal. A user reported the drifting on iOS with AUM and Ableton Link. We suspect that Ableton Link is introducing very tiny BPM changes that are not reported correctly probably. So, I can’t assume that the BPM is correct all the time and need to work around this.

You can maybe resync from time to time with the host ppq position;
Still from my experience, the drift I had in similar situation was from my own code using floating point (in double) ppq position where you add block size in sample into relative ppq which will drift because of floating point precision

Yes, ppq is probably the best solution. I have all variables set to double, in fact, there’s no drifting in hosts that report the correct BPM (Reaper). Logic just doesn’t like sending the fourth digit :slight_smile:

The drift will occur with double as well FWIW if you do something like that

posInBeats = fmodf(posInBeats + sampleToBeats(blockSize), measureInBeats)