For Dorico 2
Playback scrolling in galley view is still a hit or miss kind of thing. If you need a score to test it on I’ve got one.
For Dorico 2
I suppose the developers would be glad to have a test file. Because they wrote that they cannot reproduce this bug behavior we experience.
Seems like a good idea, ReRei; this has been a persistent bug almost since the launch of Dorico 1. It’d be great to have it fixed once and for all: it’s very real to those of us (and, although we may be in a minority, we’re real!) who are plagued by it.
Seth, what’s your environment there: Mac? Which OS?
On a related note, I find that the view doesn’t follow playback reliably in page view either. Specifically, when playback reaches a new system, if Dorico thinks that at least one staff of the playing system is in view (e.g. in the corner or very bottom of the window), the view doesn’t change and playback continues of the hidden music. This is the case even if all the music on the currently playing system could easily be fit on the screen if Dorico tried to do so.
I suppose this isn’t a bug, more a limitation. But it would be great if Dorico could try to follow playback and display all the music that’s playing, or at least as much as it can – rather than thinking that “one staff is enough” and continuing to display earlier music instead!
Could this actually be related, and a possible clue, to the infamous Green Line bug - but manifesting itself (and thereby offering a possible line for inquiry by the team) in a different way?
No! It is not related to the “green line bug”.
Is really not quite that simple. There’s certainly scope for improvement in Dorico’s playback tracking, but if it were to do what you suggest then this would end up with the view jumping around far more often, which many users may find equally unacceptable. The algorithm necessarily has to employ a number of heuristics to work out how much or how little to move. It’s a delicate balancing act that has to trade off minimising the amount the amount the view moves against the frequency of such movements. Also thrown into the mix is that the user may have moved the score manually, so in those cases we try not to move the score if at least some fraction of it is visible. It’s quite possible that we may be able to expose more options for this in the future, but the complexity of the mechanism means that presenting options for it in the UI is distinctly non-trivial
Thanks, Daniel: good to know .
Yes, I see your point. I imagine you also face the trade-off between exposing options vs keeping a lid on user-facing complexity. And the fact that the user can move the score manually during playback, simply by nudging the mouse, is of course a big benefit and helps to relieve any irritation about Dorico’s automatic behaviour.
Well, I was once given some good advice in a game design context: always listen to the problems users identify, but always ignore the solutions they suggest. Thanks for the interesting insight nonetheless!
In case it is useful, attached is a score where the view does not scroll with playback in galley view.
No file is attached, but I suspect that in fact you will find even yourself that when you reopen it, it will scroll in galley view just fine.
quite right on both counts. I won’t bother reattaching it then! Thanks
Edit: While it’s correct that closing and reopening the score fixes the problem, it is a very temporary fix. After a few minutes more of editing, the problem recurs.