Nobody is denying that there are and have been problems in this area of the software. We have devoted considerable development time in the last release to improving this area of the software. The forthcoming minor update includes further fixes (though specifically for switching mode, rather than concerning selection). I believe you would find it maddening for the software never to move the page to keep things in view. I can’t think of any other document-based software that works this way. Even Illustrator and Photoshop when very zoomed in still scroll when you drag something towards the edge of the viewport. And imagine writing in a text editor or word processor and having to scroll to bring the insertion point into view – surely this would drive you absolutely mad?
But I never find those programs disorienting. I believe that is because they SCROLL, rather than LEAP to their new location, so it is always clear what is happening. With Dorico’s behavior, if I am on measure 50 with flutes at the top of the screen, in a heatbeat I might find myself at measure 129 with bongos at the top of the screen. It quite literally can take me over a minute to regain my bearings because I have no idea what just happened, and by then, I probably have lost my train of thought. (That train doesn’t come around as often as it used to.) When the program leaps, I don’t know if I jumped forward or backward, or if I did some damage in the process.
I do take your points about the trade-offs. And that might be a way of saying it is impossible to have it both ways. If that turns out to be the case, with these big leaps being unavoidable, then I suggest you at least consider adding the visual cue of a scrolling animation, so I will at least know which direction I am being taken. I suspect such a scrolling animation would be non-trivial, but I have lost hours of time on scores where I ended up working on the wrong section of music by mistake and had to back that out.
And none of that addresses the vertical scrolling problem. There are many times in galley view when the Y position changes when that is not necessary at all.
If you have a good way to reproduce a vertical shift in galley view, then please do share it. We have, I think, demonstrated that we will resolve or at least investigate issues raised by our users if they are presented to us in a way that allows us to reproduce them, so if you have some steps or a project that you can share, please do so.
From time to time, I leave a video capture on while I am working. In every case, I have been unable to reproduce the video shift. I don’t believe it is “random” in the literal sense of the word. I believe the scenarios that trigger this are such that one simply donesn’t have a recollection of the last 3 actions that preceded the vertical shift.
I will be more diligent about leaving the recorder on moving forward.
You might try using a program like QiPress to display keystrokes and mouse clicks on-screen. I use it and find it helpful.
I use the Icecream screen recorder. I see that it has the option to display hot keys. I haven’t tried that.
This is a relatively benign example of unexpected jumping. In this case, nothing is selected. I select a single rest that is on screen, a little left of center. When I press “p” to commence playback, there is no need to shift anything because the music being played back is already there on screen. But the music does shift – to the right before starting playback. That is especially peculiar because by shifting the music to the right, that displays LESS of the upcoming music!?
Possibly a related problem: as the playback continues to measures that are off-screen to the right, no shifting occurs to keep the playback cursor in view. But strangely, if I scroll manually to get the cursor to the left of the window, Dorico resumes scrolling and keeps the cursor all the way at the left of the screen. That’s OK with me, but I doubt that was the intended behavior.
Clicking on the link to the video results in “Leider ist mit Ihrem Benutzerkonto für diesen Dateityp keine Vorschau möglich.”
(English language version of the site: “We’re sorry, your account is unable to preview this file type.”)
Click on the “download” link and then view the file.
Craig, the issue you describe in your post above whereby Dorico doesn’t continue to scroll the score during playback is discussed at great length in this thread. I’m linking directly to a reply of mine, which details the status of the problem.
That’s good to know, thank you. Have you seen the opposite situation (which I did not capture in the video, but could if needed,) where if I manually scroll (while playback is running) to where the green line is in the leftmost measure or two, the playback continues to scroll leaving the green line in its leftward position and continuously shifts the music left? That is, the music scrolls rather than the cursor line moving. It isn’t a problem, and maybe isn’t even a “bug,” per se. It just seemed to be an unexpected behavior.
No, I’ve not seen that kind of behaviour, but I wonder whether it could be a consequence of the other problem, and would only happen in the current version if you have added music such that new systems in page view or chunks of music in galley view have been added, in which case saving, closing and reopning the project should set things right (at least until such time as you add more music).
Here is an example of a most unwelcome shift both vertically and horizontally. I am working in the score in galley view. I need to add a chord to a measure. I copy the chord from one measure and paste it into the next measure to the right. At that instant, there is a big jump, moving the music up and to the right.
I suppose there is some reason for the vertical jump in order to show every staff that can display chords, but I think that is entirely unnecessary, as is any horizontal shift. I don’t need to see the bottom staff. If I want to see it, I can scroll down or zoom out. I can’t see any logical explanation for the horizontal shift in this case, as both measures were already visible in the window.
On viewing this, it is obvious to me that Dorico is redrawing the screen to put the copied material in the exact center. It is apparently coded to do that.
Yes, I have believed for several weeks that is the case. And if that is the case, can we simply nullify that line of code? It is not helpful.
I’m not sure if it is trying to center the copied material, the selected material or whatever else. It should not try to center ANYTHING. Just leave the screen where it sits. I know how to scroll. When the program scrolls in seemingly random ways, it is very hard to regain one’s bearings on a large work.
Here is another example. I had a section of music that needed to move one measure to the right. The music all was visible on the window, including the measures into which I would be moving music. In other words, there is absolutely no reason for the window to shift at all. I selected the passage. I started pressing alt-RightArrow, with the increment being 1/8 note. The first few clicks worked exactly as expected, then suddenly it shifted vertically and horizontally – even though all the affected music was already on screen. And this time it didn’t seem to center anything.
I’m not sure if this fits the “whack a mole” description but as it does involve the screen jumping around and rather than start a new thread…
I’m 34 pages and 5 flows into a piece, I’ve set things up to hide staves - this includes the vocal line I’m working on (currently a vocal line and a piano part in this 5th flow). I used galley view to enter the vocal part for the first page of the 5th flow and carried it on one more note so that part was showing in first set of staves on the second page. I then went back to page mode to finish the rest of the score on the first page. The page completed and still in page mode, I then set about continuing to enter the vocal line on page 2. However, when I reached the end of the stave the view jumped all the way back to Page 1 (the first flow).
ETA: Missed something out: As I usually do, I’d already formatted the layout of the second page (4 bars per line, 3 systems breaks, 1 frame break). The last note of the vocal line that was added before it jumped was a dotted half note in 6/8 at the start of a page 2, bar 4. i…e. it effectively started and ended that bar. If I delete that note and then enter it again, the page jumps back to the start again. I don’t know whether either of those two factors (layout, final note) had any bearing on why the page jumps but I thought it best to mention them.
Here’s another one. I needed to change pitches for two measures. All the affected music was already on screen. I got into note entry mode and did lock durations. I then entered the new notes on the MIDI keyboard. The first few notes went fine, but when I crossed the barline, all heck broke loose. The first time I did this, the screen jumped 20 measures away, with NONE of the selected music on screen. I undid all of that so I could record it. The second time the jump was unnerving, but kept the music on screen. The action pictured here seems to have tried to place the last note in the center of the window. Why? To repeat, the first time, it tossed me many measures away, but I could not recreate that action.
Lock Duration follows the notes that exist on a voice. If you’re retyping pitches and that voice then has rests for 20 bars, Dorico’s going to skip those rests to take you to the next appearance of that voice. As to Dorico jumping away from “selected notes”, “selected notes” is irrelevant - as I understand it, Lock Duration just follows the caret. It keeps going until it comes to a note in the selected voice.
No, I don’t believe it does that consistently. Sometimes it jumps 20 bars, sometimes it doesn’t. In other words, after a giant leap, I can undo that whole series of entries, scroll back to get the original passage on-screen. Then when repeating the lock durations changes, it might jump only 5 bars.
But seriously, what kind of sense would it make to jump 20 bars? Obviously that is not part of the present passage. There ought to be a limit to the gap that lock durations will jump over. I’d say it should never jump over more than 2 measures of rests, and if it is necessary to shift, it should not make a giant leap. it should shift only a bar or two at a time horizontally (never vertically) so the user can maintain his or her bearings. And please note that sometimes the jump is backwards, centering on an earlier measure, which makes no intuitive sense when a person is working left-to-right.