Logic Pro 10.1 just came out, and now the playhead's sample positions don't make sense :(
Luckily, there's another timestamp that the AU wrapper gets in its Render call which it can use, and that one seems fine.
So I suggest this fix in JuceAU::getCurrentPosition:
if (getHostType().isLogic())
{
// Use the sample time from lastTimeStamp to work around bug in Logic Pro 10.1
outCurrentSampleInTimeLine = lastTimeStamp.mSampleTime;
}
It seems that the sample time coming from Logic's transport state callback is a result of converting a sample time which is a round number for sample rate 30720, very weird..
here's a list of values from logging the current outCurrentSampleInTimeLine (when using sample rate of 44100):
10775.213949, 11798.758786, 12822.303623, 13847.284006, 14870.828843, 15894.37368, 16919.354064, 17942.898901, 18966.443738, 19991.424121, 21014.968958, 22038.513795, 23062.058632, 24087.039015, 25110.583852, 26134.128689, 27159.109073, 28182.65391, 29206.198747, 30231.17913
Thanks for the heads-up, but I'm confused by your suggested fix, since it looks to me like that would already happen in all hosts where the CallHostTransportState call succeeds. Where does your suggested code go? Perhaps you're referring to an older version of the code?
part happens only if CallHostTransportState fails.
In Logic Pro 10.1 it succeeds, so the resulting values comes from CallHostTransportState, but it just isn't a good usable sample position result.
What I suggest is to use the value from lastTimeStamp even though CallHostTransportState succeeded, but only in Logic (to work around the bug).
Here's how it looks in context: https://github.com/soundradix/JUCE/commit/0f4aec380dc46875d123a14649d90c2a393bf130
Some more info: I did some more tests and the 30720 sample rate phenomenon was in one session, but others have different, still weird, values. It may depend on the song tempo?
But what I'd prefer to do would be to not have to check for the host type... Does Logic actually set the variable to an incorrect value, or is it just leaving it uninitialised? If the latter, then we could just make sure it has a sensible default, e.g.
It's actually setting it to an incorrect value, such as 10775.213949 (see more examples in top post), which is a non-integral sample possition somewhere around the true sample position, but may be off by about a few samples
It seems that this fix has some serious drawbacks!
I have built the audio plugin demo from the lates JUCE version.
- If this is opened in Logic, the time display in the plugin is at position 0:00.
- When playback is started, the time display in the plugin is running and shows the correct position
- When playback is stopped, the time display in the plugin keeps running!
- When re-starting playback, the time display in the plugin starts running from 0 again, no matter at which position in Logic playback has been started.
That's exactly what I see here and what kept me busy all day, wondering why my AU suddenly behaves completely differently only in Logic 9 and Logic X.
For a quick experiment, I just removed getHostType().isLogic() from the check after CallHostTransportState in getCurrentPosition( ... ) and that seemed to have restored the correct behavior again.
If anything, the Logic-specific "fix" should be for Logic 10 only, as it seems to work fine in Logic 9.
Do I understand correctly that the bug this thread is about is merely about the playhead being positioned a few samples off? If so, couldn't this be the result of some rounding/truncation error with Integer math somewhere? (just guessing).
I any case, this completey breaks all Juce-based AudioUnits for use with Logic, which is pretty serious. The proposed "fix" does even more harm, because it puts the AudioUnit's internal transport time out of synch with the host's.
If this is in the responsibility of Apple, let's file a bug report asap.
EDIT: After checking several songs, I could not confirm the bug yet.
