to reproduce: get latest Juce tip (I did this yesterday), build the plugin demo and make a JuceDemoPlugin AU in Live 9. AudioPlayHead info is no longer correct, as follows:
- pos.isPlaying is always returning FALSE. So (playing) does not show up in the UI when it ought to.
- pos.timeInSeconds is always running, even when the transport is stopped.
This problem does not show up with Apple Logic. The VST version appears to be OK.
other details: Live 9.0.6 32- and 64-bit / OS X 10.9.5
Stepping into JuceAU::getCurrentPosition() shows that the AU's mHostCallbackInfo.transportStateProc is NULL.
Sounds like Ableton is just not cooperating.. If it doesn't provide a valid transportStateProc then there's not much the plugin can do about that! Maybe raise it with the folks at Ableton?
It's not pretty, but this might be useful for getting a sane test for playback.
class PlayStatusFlag {
public:
PlayStatusFlag() :
stopped(true),
wasPreviouslyStopped(true),
isPlayingIsValid(false),
ppqLastPos(0.0) {}
void update(AudioPlayHead::CurrentPositionInfo & cpi);
bool isPlaying() { return !stopped; }
bool isStopped() { return stopped; }
private:
bool stopped;
bool wasPreviouslyStopped;
bool isPlayingIsValid; // false until we spot the host updating the flag
double ppqLastPos;
};
void PlayStatusFlag::update(AudioPlayHead::CurrentPositionInfo &cpi) {
// Can we use the flag?
if (isPlayingIsValid) {
stopped = !cpi.isPlaying;
return;
}
// If not, is the flag set and we can trust it in future?
if (cpi.isPlaying) {
isPlayingIsValid = true;
DBG("Using cpi.isPlaying flag which appears to be valid");
stopped = false;
return;
}
// Otherwise, have we not moved? A sign of stoppage.
if (ppqLastPos == cpi.ppqPosition) {
wasPreviouslyStopped = true;
stopped = true;
return;
}
// Otherwise, were we stopped last time and now we've jumped?
if (wasPreviouslyStopped &&
((cpi.ppqPosition < ppqLastPos - 0.5) ||
(cpi.ppqPosition > ppqLastPos + 0.5))) {
ppqLastPos = cpi.ppqPosition;
stopped = true;
return;
}
// Otherwise, looks like we are playing.
ppqLastPos = cpi.ppqPosition;
wasPreviouslyStopped = false;
stopped = false;
}
That makes sense, except that this used to work. The previous version of Aalto works (syncs clock) with the same version of Live just fine. Released in May, it used a then-current Juce. Can you think of any changes made this year that might affect the transportStateProc connection?
[a half-hour passes...] I just checked out Juce 2.1.8 (Nov 2013) and tested the plugin demo. The behavior is different but not in the way I was expecting. The timecode in 2.1.8 is simply reporting zeroes, not going haywire. The transport state is the same as the current version: not working. So the transportStateProc issue was a red herring, and probably Live has never been giving the callback to Juce. I'll have to look to other differences to explain why my host sync stopped working. Sorry for any confusion.
I fixed a bug a while ago whereby the 'playing' variable could have been an uninitialised value. Perhaps in the past you were getting fake 'true' results because of that?
I've got some test code somewhere which measures discrepencies in the various DAWs providing play position data. I'll see if I can dig it up (or the results from it) there were some pretty weird issues with time going backwards as well as play flag problems..
I have noticed that Logic will send "backwards" times on occasion, and spit out a seemingly totally random value once in a while on stop / start. I have some sanity check code that's all there because of Logic.
Fairly often it seems that the AP thread is fine, and the MessageManager thread gets incorrect values. werid.
You know that you're only supposed to get that playhead info on the audio thread during the audio callback, right? It's not guaranteed to work at all if you call it from the message thread.
