D3 score still jumping around during editing

I too have encountered this issue on occasion. It seems that it happens if I have something selected [a note] in page view, then scroll to a different area of the score to look at something else. All of a sudden I’m transported back to the selected note, with [apparently] doing anything. Whether is was an attempted mouse click, or a click on a scroll bar (or a missed click on a scroll bar), or a key press, I’ve not determined what actions caused it. But it does happen randomly. If I can determine what caused it (and can reproduce it), I’ll post here. I work primarily with shorter/smaller scores, so it’s not a big issue for me, but I can see how disorienting this could be in a long large score.

Exactly the same. I encounter this maybe once every 30 minutes or so.

I can reproduce this 100% of the time with the following:

  1. New from Template/Solo/Lead Sheet
  2. 4/4, add 100 bars
  3. Switch to Galley View
  4. Enter a C quarter in bar 1
  5. Enter a D quarter in bar 40
  6. Enter a E quarter in bar 80
  7. Scroll back to bar 40, select the D and delete it
  8. Scroll to bar 80, select the E
  9. Hit Ctrl-Z twice to bring the D quarter back
  10. Scroll to bar 80 and select the E
  11. I’m magically transported to bar 49-51 for no apparent reason at all

I believe Claude’s intent was simply to ask if Steinberg’s staff ever experiences these problems? It is one thing to say it is an acknowledged problem affecting the whole base, including the development team, but the problem has been intractable so far because even the Steinberg team can’t reproduce the problems as they experience them.

It is another thing to imply that this is a rare condition that is never seen by Steinberg’s staff.

In any case, it seems to me that at least some of the jumping problems have been reduced in recent releases. I not get an unexpected (and disruptive – sometime destructive) jump about once every 5-10 minutes. In earlier releases it was happening much more frequently than that.

These steps don’t result in this result. When I scroll to bar 80 and select the E, there’s no further movement of the score. Could you please make a screen recording showing this?

This was reproducible for me on Windows.

Note, I had to press Ctrl-Z three times not twice to get the D quarter back, so there is presumably some room for interpretation of exactly how to do the steps.

Following the steps exactly is was reproducible on W7…

edit: also 100% reproducible on my W8.1 laptop

If it helps, here’s a macro recording of exactly what I did:

local app=DoApp.DoApp()
app:doCommand([[File.New?Template=Lead sheet]])
app:doCommand([[Window.SwitchMode?WindowMode=kWriteMode]])
app:doCommand([[View.ZoomScoreLayoutView?ScoreLayoutViewID=0&ZoomLevelType=kPercent&ZoomPercent=150]])
app:doCommand([[Play.SetProjectAudioEngineState?BlobID=0]])
app:doCommand([[Window.SwitchLayoutAspectType?LayoutAspectType=kGalleyViewAspect]])
app:doCommand([[Edit.GoTo?FlowID=0&Index=1]])
app:doCommand([[Edit.SelectAtPoint?X=76.6667&Y=112&AddToSelection=0&BlockSelection=0&NextSelectionAtPoint=0&SelectionTriggerAction=0]])
app:doCommand([[NoteInput.EnterAtPoint?X=76.6667&Y=112&Set=false&LayoutAspectType=kGalleyViewAspect&LayoutID=0]])
app:doCommand([[NoteInput.NoteValue?LogDuration=kCrotchet]])
app:doCommand([[NoteInput.CreateTimeSignature]])
app:doCommand([[NoteInput.CreateTimeSignature?Definition=4/4&UseLocalOverride=0]])
app:doCommand([[NoteInput.CreateBarLine]])
app:doCommand([[NoteInput.CreateBarLine?Definition=+100&UseLocalOverride=0]])
app:doCommand([[NoteInput.Pitch?Pitch=C]])
app:doCommand([[NoteInput.Exit]])
app:doCommand([[Edit.SelectAtPoint?X=2011.33&Y=104.667&AddToSelection=0&BlockSelection=0&NextSelectionAtPoint=0&SelectionTriggerAction=0]])
app:doCommand([[NoteInput.EnterAtPoint?X=2011.33&Y=104.667&Set=false&LayoutAspectType=kGalleyViewAspect&LayoutID=0]])
app:doCommand([[NoteInput.NoteValue?LogDuration=kCrotchet]])
app:doCommand([[NoteInput.Pitch?Pitch=D]])
app:doCommand([[NoteInput.Exit]])
app:doCommand([[Edit.SelectAtPoint?X=3961.33&Y=105.333&AddToSelection=0&BlockSelection=0&NextSelectionAtPoint=0&SelectionTriggerAction=0]])
app:doCommand([[NoteInput.EnterAtPoint?X=3961.33&Y=105.333&Set=false&LayoutAspectType=kGalleyViewAspect&LayoutID=0]])
app:doCommand([[NoteInput.NoteValue?LogDuration=kCrotchet]])
app:doCommand([[NoteInput.Pitch?Pitch=E]])
app:doCommand([[NoteInput.Exit]])
app:doCommand([[Edit.SelectAtPoint?X=1998&Y=106.667&AddToSelection=0&BlockSelection=0&NextSelectionAtPoint=0&SelectionTriggerAction=0]])
app:doCommand([[Edit.Delete]])
app:doCommand([[Edit.SelectAtPoint?X=3926.67&Y=102.667&AddToSelection=0&BlockSelection=0&NextSelectionAtPoint=0&SelectionTriggerAction=0]])
app:doCommand([[Edit.Undo]])
app:doCommand([[Edit.Undo]])
app:doCommand([[Edit.SelectAtPoint?X=3952&Y=100.667&AddToSelection=0&BlockSelection=0&NextSelectionAtPoint=0&SelectionTriggerAction=0]])

But note: just replaying the macro leaves me looking at bar 1 of the score, for whatever reason.

I won’t have access to a Windows development machine until Wednesday, but I’ll look at this again then.

Sure, here’s a gif of steps 7 through 11 on Win10. After step 11, bar 49 is the leftmost measure on the screen.

Happened to me too. Here’s a video: - YouTube

Credit where it’s due - that seems to have been the post that unstuck the reproducibility problem :wink:

Further still, I really don’t see the problem with Daniel’s request. Somewhat ironically, it does feel a tad like when you hear your car make a noise and you take it to the mechanic and then… gosh darnit now it isn’t making the noise, lol. But by and large, I don’t think it unreasonable to ask us to share projects or describe the manner in which it is happening. Otherwise it’s a bit like asking a doctor to come up for a treatment plan without sharing your medical history.

Romanos, they are called Heisenberg bugs. As soon as you try to find where they are, the uncertainty principle of quantum mechanics kicks in :slight_smile:

This case is not reproducible on my Mac. But there are definitely some jumping issues on Mac too, but mostly jumping to the selected note:

  • this morning I was just looking at my music in Dorico for like 30 seconds, without touching any input device, and then the screen jumped all of a sudden to the selected note (which had been out of view)
  • Also when starting a pinch gesture on my trackpad to zoom, the music often jumps to the selected note (but not always, maybe 3% of the times.)
  • And when I’m using another application, and then I move Dorico to the front by e.g. cmd+tab it also sometimes jumps to the selected note

(3.0.10)

As I wrote above, that’s why I make a point of making sure that nothing is selected before doing anything not related to input or editing.

Yes, I suppose we have all trained ourselves to do that, either consciously or sub-consciously. That does help if you can remember to do it. But I don’t think that is a solution, per se, especially as it is bound to confuse and/or irritate new users.

The software should be smart enough to recognize that there is a selected item off-screen and not make the leap back (or forward) to that point. This should be especially true in either of these cases:

  1. The current action would not change that selected item in any way.
  2. There are multiple selected items and it is impossible to display all of them simultaneously without changing the zoom level.

Also, there are still some cases when in galley view, the window shifts vertically. This isn’t as pervasive as it used to be, but it still happens on occasion. when working in a large score, I find that quite distracting. There should never be any vertical shifts when in galley view, IMHO.

Not even if you move or extend the note entry cursor to a staff which is off the screen? Or if you want to define a tempo, system text, etc, and the top staff is off the screen?

No. There should never be ANY automatic vertical shifts in galley view. I know which instruments I am working on. I scroll vertically to get the present instrument in view. The software never knows better than me. If I want to work on another instrument, I’ll either hit the scroll wheel on my mouse or switch to another window that has the instrument(s) I’m interested in.

If I want to adjust system text or tempos, I’ll scroll to get it into view. IMHO, that is the main point of galley view – to work left and right, not up and down.

If I want to extend the entry cursor, then I’ll invariably zoom to a level that gets all the affected staves on screen, and again, I know better than the software. In that scenario, what is the point of the software scrolling down to include the lowest staff involved in the entry caret an in the process, shoving the highest one out of view? Makes no sense to me. The only thing that makes sense is to either zoom to get all of it in view or to leave it alone and live with some of the entered notes being below the visible window.

I wonder if this has something to do with auto-save?
I’m not sure why that would be the case, but considering auto save happens on a recurring basis there might be some sort of bug associated with it.