I don’t think so. I have autosave off by default (it’s too slow and disruptive on very large projects) and I still reproduce the Windows bug in this thread.
Well, I guess the software is either going to please you or me, but not both of us 
I find the idea that you want to be able to create something you can’t see is just strange. Unless you are the sort of user who never ever makes a “mistake” and presses shift-T when the top staff isn’t in view, or whatever.
I can’t “see” it if it leaps to another location even within the visible page. When that happens, I have to stop to figure out what happened. To me it is far preferable to have the palette remain steady while I am trying to paint.
Here’s an example of that disruptive vertical shift that happened moments ago. I have a custom score that has timp, harp and strings. I have a long roll on the timp (going on about 8 bars). The timp is the top staff. I need to extend that roll a few bars. I select the drum note and “R” that a few times. By now, the beginning of the trill (roll) is off-screen to the left. I click on the visible part of the trill to expose the right handle. I drag that handle to the right 3 bars.
At that instant, Dorico decides the timp roll should be in the vertical center of the screen. That leaves me with the top 45% of the screen being white space and my strings have now shifted off the bottom on the screen. How does that behavior make any sense? It doesn’t. That’s why I say we would all be better served if Dorico would simply never try to make any vertical adjustments while in Galley view. IMHO, horizontal shifts are sometimes debatable. Vertical shifts are never a good idea.
And as we can predict, I am not able to repeat that behavior. THese things just seem to jump up and then disappear for awhile.
You are not alone.
This behavior of Dorico annoys me as well.
Agreed. I often want to shift my score to see specific parts. I don’t need Dorico moving up or down on me.
I’ve also discovered that the zoom in behavior is not the same for all objects. If you select a note and zoom in, the view tends to zoom in on the note selected (this is great) but that doesn’t work for me with slurs for instance. I wish this would be standardized.
I had not noticed this. That’s a fine suggestion, albeit a subtlety. Some of the best features in software are things one doesn’t really notice.
I think the zoom behavior you describe is similar to how Google Maps zooms on web browsers. If the mouse is hovering over a point in the upper-right of the map when you use the scroll wheel to zoom, that location remains on the screen. In other words, the locus for the zoom is not the center of the window. It is where the mouse is. Similar behavior in Dorico would be very welcome, at least when using the scroll wheel for zooming.
1 Like
Dorico already has this feature, called (I think) “focused zoom.”
If you have a note selected in the corner of the viewing area, zooming in will keep it in the viewing area.
It works for Z. Not sure about zooming using the scroll wheel.
Nice to know. But personally I think it is an architectural (or philosophical) error to base so much of the positioning on the selection. It is perfectly normal for selected objects to be off screen. That happens all the time when using the “P” command to play back a section of music. If a selection is on the screen, then I can see an argument for taking that into consideration. But if a selected object is already off-screen, it should not be used as part of any positioning decisions, IMHO. After all, it is off-screen for a reason. I put it off-screen because I was interested in seeing something else.
I don’t think it is. If a selection is off screen, Z does not jump to selection.
Was this ever reproducible in house? I’ve been experiencing this bug a lot and realized a pretty serious twist on it yesterday. If the score jumps while trying to paste a section with Ctrl-V or Alt-clicking, Dorico copies the music to the wrong spot!!! Instead of pasting where I clicked, it pastes to wherever it decided to jump. This has the potential to be pretty catastrophic if the user doesn’t immediately catch that Dorico just copied the music to an unintended spot in the score.
Of course now that I’m not on a deadline, I can’t seem to find an example to reproduce it. If I can find an example today when I have more time to investigate, I’ll post the steps, but everyone should be aware that if your score jumps while pasting, your music likely was just pasted to the wrong spot.
one I have experienced multiple times.
transcribing (entering notes) in galley view, last entered note selected (see attach)
click the “fixed Tempo mode”
booom
Dorico moves the window to the first bar
scroll back to where you where
click the “fixed Tempo mode”
booom again
That’s why I make a habit of deselecting everything before doing anything. Unfortunately this doesn’t always help. Occasionally pressing an arrow key selects something even though nothing had been highlighted.
Do you mean “Fixed Tempo Mode”? I admit I have never used this, but your situation does seem an inconvenience. I tried it on a file of mine and did not experience your situation. I am not sure what I am doing differently.
yess indeed “Fixed Tempo Mode” !!
I corrected it in original post
Try toggling the Fixed Tempo Mode button during playback. Under some circumstances (and yes, at some point I’ll put together a reproducible case) the playback line will show a completely different flow to the one it’s actually playing back.
Does it always jump in one direction (forward, backward)?
Does adjusting the tempo pull-down faster or slower affect the direction in which it jumps?
The problem where changing between fixed and following tempo can cause the window to jump when playback is stopped has been fixed ahead of the next update.
Great news!
Hahaaaa
Yess one less
I have never used the fixed playback button. I didn’t know it existed before the Facebook stream this week. But I have had some occasions where using the “P” command has causes unexpected jumps when stopping the playback. It is possible the fax addresses those cases also?