During playback, the virtual keyboard animates the keys with a variable amount of advance over the music, about one beat ahead in my attached project file. I only experience it on the the desktop version (Mac), as the animation is fine in Dorico for iPad. The playhead is well synchronized to the music in both versions too.
Is there any parameter that I might have accidentally changed that could cause this?
Attached is an example project for anyone to test.
test delay.dorico (932.8 KB)
Perhaps you’re using a very large buffer size in Edit > Device Setup?
Thank you for your reply. No, I don’t think I touched this parameter, value is 256 (the default?)
I think I have found some explanation: it seems to be related to the bluetooth interface (I mostly use bluetooth headphones), and this interface has some inherent delay to it. However, the playhead seems to take this delay into account (does it?), because it is in sync with the audio, but not the virtual keyboard animation.
If I switch to using the built-in speakers, the delay is much less perceptible.
Interesting fact: during my tests, I noticed that the delay (with built-in speaker) can be made barely noticeable (except for the first measure) if I scroll the view during playback. As a bonus, the playhead animation becomes much smoother (as opposed to stepping forward when not scrolling the view), as some redraw events seem to be forced by scrolling the view.
I made three videos to illustrate this thread: one that clearly shows the delay with BT (even without sound), and two with sound that show the effect of scrolling as explained (in these two I used the built-in speakers, so the delay issue is minimized compared to bluetooth). (Delay improvement can be better appreciated by looking frame by frame).
The way the keyboard animation works is that the keys are shown as depressed at exactly the same moment the notes are sent to the audio engine. The playhead is positioned according to time updates that are received from the audio engine, but we don’t receive updates when notes are actually played. Perhaps in future we can make this system more sophisticated, such that we can record the time position at which each note is supposed to be sounded, and then run the keyboard animation off the same time updates the playhead uses. We’ll think about it for the future, but it’s unlikely to be something we work on imminently.
Thanks Daniel. As long as it is logged somewhere for your future plans, I’m good with that 
It’s a minor issue and it doesn’t stop one to do the actual creative work efficiently.