AudioPlayhead::CurrentPositionInfo determining position in bar



I have a plugin that depends on syncing to the playhead position within a beat and the beat in the bar.

My question is about hosts that do not populate ppqPositionOfLastBar.

In that situation you only have ppqPosition to go on and any odd time sig changes e.g. 7/8 back to 4/4 will throw even the beat count off by 0.5 when counting beats in the 4/4 section.
Bar starts will be affected by any time sig change.

Wondering how people handle this situation ?

I read in the documentation the pro tools doesn’t populate this field so I am wondering if I am missing something.


Hey, I’m running into the same problem here and wondering if you, or anybody else, has figured out a reliable solution to this?

In situations where we can get a real value for ppqPositionOfLastBarStart, I think we can easily identify where we are within the current bar:

if (hostInfo.ppqPositionOfLastBarStart > 0.)
    auto barLengthInQuarterNotes = hostInfo.timeSigNumerator * 4. / hostInfo.timeSigDenominator;
    auto positionInBar = (hostInfo.ppqPosition - hostInfo.ppqPositionOfLastBarStart) / barLengthInQuarterNotes;

However, when we can’t get a real value for ppqPositionOfLastBarStart I don’t see a reliable way forward. My current code for this case looks like this:

    auto barLengthInQuarterNotes = hostInfo.timeSigNumerator * 4. / hostInfo.timeSigDenominator;
    auto numBarsElapsed = hostInfo.ppqPosition / barLengthInQuarterNotes;
    auto positionInBar = numBarsElapsed - std::floor(numBarsElapsed);

Unfortunately, as you pointed out, this code carries the implicit assumption that the current time signature information is the same time signature that has been in use since the beginning of the track. That assumption could obviously be wrong, but we don’t get enough information to determine that.

So is there a better way to go about this? Am I missing something? Without being able to confidently calculate my position within the current bar, my sync behavior gets messed up.


A little more research…

It seems like there’s not really a good answer to this question, and that plugin developers are all sort of independently coming up with various ways to mitigate or step around the problem.

Hoping that’s not truly the case but that’s my read on the situation currently :slight_smile:



Been a long time since I posted that, but I got an email alert and recalled having the issue and it piqued my interest.

I have checked the plugin I was developing at the time and it looks to be working fine time positionally with changes thrown at it including time sig and tempo - but can only check with Cubase which I use as a guitarist and musician rather than a dev - so Cubase might be populating bar changes.

I had more hosts going when I was developing and asked that question.

Will have to go through the code in detail to see what my solution was (if any)

I am still very involved in audio apps as a musician but as a C++ dev I am freelancing outside audio atm - so it will be w/e at the earliest


Hey yea no worries, would love to see what you came up with whenever you get around to it!