Spontaneous movement in galley mode.

I have a project that contains a bunch of short flows (8-10 bars each). I’m working on one flow, which easily fits entirely on my screen in galley mode. I select the first note in the flow and hit “p”. The display instantly shifts so that the first note is slightly to the right of center of my screen, shifting half the flow off the screen. Then, when the playhead gets to the edge of the screen, it goes off-screen, even though I have “Follow playhead during playback” selected. I’m now left looking at the first half of the flow while the second half plays. If, while playing the first few notes, I drag the flow to the left so I can see the whole thing, it immediately jumps back so half the flow is off-screen. To see the entire playback, I have to wait until the playhead is almost to the edge of the screen and quickly drag it to the left.

I can see the logic in trying to keep the playhead toward the center of the screen. It might even be kind of nice to have the playhead stationary and have the music smoothly scroll left under it. And I can sort of see the logic in moving the playhead to the left of the screen, and shifting the music only when the playhead gets close to the right edge. That sort of minimizes the number of shifts. But starting playback by shifting the music so that the playhead will soon disappear off the screen doesn’t seem like what anyone would want.


iMac. Retina 5K, 27-inch, Late 2015. Mohave 10.14. Dorico

This has been discussed at length. The next update promises improvements in this area.

Here, for instance.

Right, known issue apparently. Not being able to follow playback like this is such a major defect that I can’t imagine how Dorico got to 2.1 without this being fixed. Restarting Dorico is the only thing that sometimes helps for me.

In general, Dorico does follow playback in both page view and galley view. We know that some users experience a problem whereby Dorico stops following playback in galley view. Nobody has yet been able to isolate the circumstances under which this problem occurs. Despite a good deal of concentrated effort from our internal testing team, we have similarly been unable to pin down the cause of the problem, because we have not yet been able to reproduce it at all internally. I believe we have a pretty good record of fixing bugs quickly and thoroughly, but no software development team can fix a bug that they cannot reproduce. As soon as we can reproduce it, I feel sure we’ll be able to fix it.


Would it be a good move to ask those of us who do (seemingly predominantly Mac users) to send you system configurations to see if a matrix can be produced to isolate what we all have in common?

Agreed with thanks!

No, Mark, I very much doubt it’s specific to any particular configuration such as operating system version, amount of RAM, screen resolution, etc. It seems most likely that some combination of actions has to take place that causes the program to lose track of the playhead during playback, perhaps over a long period of time, and it will not be related to your system configuration.

just a thought… could it somehow be related to running multiple monitors with different resolutions? I experience this very frequently and my desktop is shared by two HD, one 2K and one 4K display, the latter two in portrait orientation…

I only have one monitor. It also happens in Page Mode, alas.

I have the exact same situation, and I CAN reproduce it invariably. It happens every time (with no exception) the score is playing (with the option to follow the playhead turned on) and I move the score backwards so that the moving playhead gets lost in the far right side of the screen; the score immediately jumps to where the playhead is, but gets stuck in the far left side of the screen, so the score keeps moving instead of the playhead.

That sounds like a different problem, Josue. In the cases reported by a handful of other users, the issue is that Dorico stops following the score, and the playback line scrolls out of view to the right, but the screen never moves again to catch up with it.

Strictly-speaking Daniel (and with all due respect… really!), I experience a variety of ‘versions’ of this phenomenon/bug. They do include one pretty close to what Josue describes, although - as your team knows - it can’t be reliably reproduced, as Josue’s can.

There are times when I move the score either forwards or backwards (using the bottom slider); then it (the score) moves in such a way that the window refresh excludes the playback line - but does keep moving.

It can also happen that the score tries to ‘catch up’ (or I make it do so), and does indeed scroll forward (to the right); but the playhead is still not visible.

Hope this is helpful.

Today I copied one entire flow (I was using it as a sandbox) and pasted it into my primary flow because it was sufficiently ready for inclusion. But no matter what I did, once playback reached the point where my newly pasted material started, playback scrolling stopped completely. The score sat there while the content played on to it’s conclusion.

This is not said as a complaint. Rather it is offered as another “data point.”

And you’re on Windows, DaddyO?

Conventional wisdom was - and AFAIK still is - that the bug is restricted to macOS. Hmmmm…

I see this on PC too FWIW.

I see this problem only occasionally, but it appears to have sort of a pattern (at least for me). If I’m transcribing a score with 30 or so staves, I usually enter the music one staff at a time and then play it back to check for wrong notes. In Galley View, Dorico scrolls just fine until I have about five or six staves with music entered. After that, it stops scrolling during playback until I enter music on a few more staves, and then it starts scrolling again just fine. As I continue to add music to subsequent staves, scrolling continues to work fine. So it seems scrolling during playback works fine when only a few staves have music, and it works fine when a whole bunch of staves have music, but it has problems with the in-between case.

Thank you, Daniel. Understood. Makes sense.

Since it does appear to be a bug affecting both platforms, could it then be due to the positioning of the score as a result of - as you hint - something which has just happened… such as a window re-size, or an act of scrolling, or some other movement of some part of the window etc?

Thanks for continuing to work on it.


Indeed, Mark, Windows 10.

And I don’t have a slew of staffs, just standard Classical era orchestra, and not all of them have notes. Although I have experienced some of the playback issues others have reported, this particular behavior only started with this particular project in which I copied one Flow and paste/appended it to another. At the point of the paste, the Playhead stops scrolling.

I know all of this is anecdotal, and it sounds like fixing such things isn’t easy because most are not reproduce-able. I can’t review it today, but I will tomorrow.

Just a thought: do those users who experience this problem work with the Transport window shown or hidden? I mean the pop-up Transport window, not the mini-transport controls on the main window toolbar.

Another thought: I think this could be a different bug. If one flow is appended to another it could be that it somehow results in it being in a different render chain which could explain why the playback line stops moving (since currently we only track playback in the first render chain).