I don’t think FInale makes any attempt top keep things in view. If you want to scroll, you scroll. The music doen’t move around on you.
Yeah, Finale has almost no comparable function with the arrow keys.
One thing in particular I’m seeing in Dorico: When I have a lead line (melody and lyrics) that’s part of an orchestration, and I’m using the arrow key to advance through the melody, sometimes the arrow will go to the next lyric instead of the next note. That’s annoying. And sometimes when I get to a new measure, it will advance to the measure as expected, but in an entirely different player.
I’ll have to pay more careful attention to quantifying this behavior, but it seems that the problem is primarily vertical - i.e., the horizontal movement is predictable, but the choice of “row” is not. At least for me, using the arrow advance function. (I know that’s not exactly a matter of zooming)
I’m not an expert with Finale by any means, but I’ve just run it up and find that if I switch to the Simple Entry tool, hitting left/right arrow key when zoomed in does move the score to bring things into view, which is what I’d expect (I would find it maddening if I had to scroll the score manually all the time – imagine if Microsoft Word didn’t automatically bring the line you’re typing on into view!).
Dan, the issue with what gets selected when you hit the left/right arrow keys is, to my mind, unrelated, or at least I think it should be. The issue of what gets selected has been discussed at great length here and I’d prefer not to rehearse it again in this thread, because that’s well understood and we have already said that, in due course, we will replace the graphical navigation in Write mode with something else.
I am interested in hearing from Craig about when the program apparently moves on its own to a completely unrelated area of the score, to the point where you can’t even work out what part of the music you’re looking at. That’s an experience that I don’t think users are having in general, so I want to understand more about Craig’s issue. I don’t need to know any more about how people feel about what happens when they press the left and right arrow keys in Write mode. Thanks!
Daniel,
If it helps, at all, a few times in page view if I am selecting a range of measures (some of which are out of view) the screen jumps around to a place that confuses me at first. It isn’t consistent, and I don’t know what causes it.
But I click in the middle of the bar to select all of the contents, then scroll to the last bar and while holding shift I click on the middle of the bar. Sometimes, Dorico jumps back to the start of the selection, sometimes it doesn’t, and sometimes it seems to jump to the middle of the selection. If Dorico did jump somewhere in the selection, the selection which might have been in the middle of the screen, might now also have jumped a little further up.
While this doesn’t slow me down to the point of not being able to work. I do find myself disoriented at first, and often have to scroll over to see instrument names to guarantee what I had selected had actually been selected. For sure, this is where a ghosted bar number and ghosted instrument name would be awesome to have in page view and galley view that propagates on all of the staves would come in handy.
Sorry if this isn’t descriptive enough.
Robby
I’ve done some testing regarding jumping to unexpected staves when using arrow keys.
Setup: a new Dorico 2.1 file created from the string quartet template. Filled all four parts with a regular pattern of notes, and tried navigating with the arrow keys under various circumstances.
In page view, if I type arrow-right repeatedly, the selection will jump to the first element in the topmost part that has any note in the first bar of the next system. If you are in the viola or cello part, then you jump to V1 only if that first bar isn’t empty, otherwise you end up in V2 (if it’s not empty). The topmost part in the next system may be the closest object around if you leave a low part in the previous system.
This may be intended behaviour, but I don’t like it very much. I expect to move to the next event in the same part if its staff is present in the next system.
But the jump also occurs in galley view, which is weird and unnecessary. I discovered a regularity. In my string quartet setup, arrowing rightward in any of the lower parts always jumps to the topmost non-empty part (often V1) at the beginning of any bar with a bar number that is a multiple of 5.
After changing the meter, the jump is still on bar 5, 10, 15 etc., so it’s not the rhythmic position in the piece, it’s at certain bar boundaries.
Also checked with a different project (brass quintet), the issue is the same. So I guess it has nothing to do with a certain instrument or ensemble.
It only happens arrowing from left to right, not if you are using arrow-left. Then you always stay on the same staff.
When using no meter at all (X, or just unspecified), the jump still also occurs in galley view, but then only where the bar number 1 is repeatedly shown in blue above the top staff, which appears to be after every 16 crotchets/quarter notes, regardless of the rhythm underneath. Clicking in the staff also selects that amount of music, BTW.
Playing around with this some further (after testing without meter, I inserted common time again), the behaviour is suddenly the other way round: now you jump to the bottommost part with music in that bar. But, in galley view, still at bar numbers that are a multiple of 5. In page view, you now jump from any of the violin parts to the (non-empty) cello staff at the system break. Now, it’s not even the closest staff seen vertically, so probably not intended behaviour.
HTH! Maybe this is of any use to the developer team?
Dear fellow Doricians,
Daniel wrote:
I am interested in hearing from Craig about when the program apparently moves on its own to a completely unrelated area of the score, to the point where you can’t even work out what part of the music you’re looking at. That’s an experience that I don’t think users are having in general, so I want to understand more about Craig’s issue. I don’t need to know any more about how people feel about what happens when they press the left and right arrow keys in Write mode. Thanks!
I feel the last writers have not read Daniel’s post — which would be quite surprising, since he’s like the God of Dorico. Ok, read it again, and let Craig explain Daniel what specific problem he’s had.
The erratic/cumbersome/not-always-useful behavior of arrow keys in Write mode is very well known and we’re not helping here by keeping this thread open with redundant information!
I experienced quite some jumping around if I do some copy-or-cut-and-pasting and the region I work with starts with empty measures.
When I select bars 1-80, and bars 1-10 are empty, and you paste the music into bar 1 of another player, it gets somewhat unpredictable where the screen will end up after those operations.
I think I’ve seen a thread where this was brought to attention, I got the impression it’s on the to-do list.
I have tried to be as specific as I can be, given that this is a problem that seems to come from out of nowhere. It is extremely disruptive to the compositional process precisely because it happens when you are not expecting it. And that makes it difficult to try to pin down some deterministic behavior. But I promise to try to do that, and I certainly welcome any observations others have about this behavior.
I am wondering if there is a problem of philosophies rather than implementations. That is to say, it is entirely possible that the designers – having lived with very similar behavior through the Sibelius days – may consider this behavior normal, even desirable.
My view is that page mode naturally involves recasting of page layout on an ongoing basis. I fully expect pages to jump around when writing in page mode. If I am doing a simple exercise involving a single instrument, I might choose to work this way because that simple case is not too disorienting. But in general, I cannot cope with pages jumping around, so I use Galley view 90% of the time when in write mode.
It is my opinion that galley view should NEVER jump around, other than to stretch or shrink measures to reflect the contents of the measures. Other than that, there should never be any horizontal moves. That is what the scroll wheel on the mouse is for. And the program should never cause any vertical movement under any circumstances. Again, that is what the scroll wheel is for. If I want to scroll left, right, up or down, I’m perfectly capable of that. If I paste material that extends beyond the right of the screen, so what? Leave the view where it is – at the beginning of the insertion point. If I want to look at the end of the paste operation, I’ll scroll there or zoom out. If I add system text and it is placed above the window, so what? If I want to see that, I’ll scroll up or zoom out. If I enter a bunch of 32nd notes that push measures off the right of the screen, so what? I’d rather manually scroll than have the program jump somewhere – forcing me to fight to regain my bearings.
I cannot think of any good reason why the program would want to jump around. If it a case where the scrolling is an unintentional by-product of the overall implementation, I can easily understand that, but I think it should be considered a bug when talking about galley view.
If this truly is a philosophical difference, then I would suggest a possible compromise would be for any programmed jumping to be done as an animation, where the music “glides” to its new position so that the user can maintain bearings. I suppose that is a non-trivial thing, but IMHO, having to throw out work because the program confused me into making a mess of my score is also a non-trivial thing.
I have the same issue, when inserting notes or lyrics it happens all the time that the view changes putting my insert caret in a weird place (extreme corner of the screen, almost out of view) and I have to search where it is gone. Sometimes I must move the view manually to be able to continue.
It seems to me it happens in page view but I have to test more.
I too have noticed some occasional erratic behavior where the screen jumps to someplace unexpected.
Fortunately it does not happen often. 
Unfortunately, I have not picked up any specific pattern, nor do I have a repro. 
My suggestion to anyone who sees this is - the next time this happens, try to back up and get a specific repro to Daniel. Once Daniel & the development team have something specific they can analyze it and either explain why this is happening (if expected behavior) or fix (if unexpected)
Do you really think this, Craig? It’s not how Finale works, as far as I can tell. In Finale in scroll view, as I input notes towards the right-hand side of the screen, as soon as I get into a bar that doesn’t fit completely on the screen, it moves that bar to the left-hand side of the view. And it doesn’t give me much of a clue what’s going on: because the brackets, staff labels etc. are drawn the same way if bar 100 is at the left-hand side of the screen as if bar 1 is there, and because the bar number is only displayed above the top of the system by default (I’m using the default orchestral template, and of course I’m sure other templates have other settings), I find myself completely disorientated. I do see that there’s a ‘Measure’ read-out in the status bar at the bottom of the window, which tells me which bar I’m in (for what it’s worth, as I mentioned in another thread, last weekend I spent some time putting a similar kind of read-out into Dorico’s status bar, so that will also tell you the bar number of the current selection in future, which may help, and we’re also in the process of making the light blue bar numbers that currently appear only at the top of the system appear on every staff in galley view, to help with orientation).
In the Simple Entry tool, I can also navigate up and down with Command-up/down arrow and bar to bar with Command-left/right. When navigating up and down, as soon as I reach a staff that’s not in view, Finale brings one more staff into view, so that the selection and/or caret stays at or near the bottom of the screen. But when navigating left and right, as soon as I reach a bar that’s not in view, Finale brings as many bars as possible into the view, so that the selection moves from the right-hand side of the screen to the left-hand side of the screen.
Again, I’m no expert on Finale, so it’s quite possible that there are settings to prevent it from moving the music around at all even in galley view, but this is the default behaviour as I see it on my Mac.
Dorico really isn’t all that different: when you move right in galley view, and it needs to bring the next note or bar into view, it will move the selection or caret as close to the left-hand side of the screen as it can (as Finale does): this seems sensible to me because it is intended to minimise the number of moves, i.e. fewer moves, but moving as far as possible each time, since if you’re inputting or reading music, you generally want to see the music in front of you more than the music behind you. When moving left and right on the same staff in galley view (and notwithstanding that when you are just hopping the selection rather than moving the caret, it is possible for a different staff to get selected), the vertical position of the staff relative to the viewport will not change.
When you move up or down, it follows the same philosophy: it moves the new item as close to the opposite side of the screen as possible, so that you don’t need to move the screen again immediately if you keep moving in that direction. If you move up, then it will bring the staff you’re moving onto to the bottom of the viewport. This is different from Finale, of course, which moves the smallest distance possible when moving vertically, in order to bring only the next staff into view.
So I am a bit unsure that what you really want is for Dorico never to move the screen in any direction, since I don’t think I would want to have to assume the responsibility of moving the screen myself all the time, and it’s also not how other software of this kind works, including Finale, as far as I can tell.
I hope that at least by engaging you in detail on this issue you see that I do not consider it a trivial matter, and I want to make the program better in this regard. But I know you are coming to Dorico after years of using Finale, and I find that Finale’s automatic movement of the score in scroll view is very similar to Dorico’s movement of the score in galley view, and so I need to know more about what specifically doesn’t work for you.
I always used Speedy entry, not “simple entry”. It is possible that those two modes behave differently. But I will assume they scroll the same way. I don’t think I said (at least I didn’t mean to say) that Finale never scrolls music to the left as notes are atted in the last measure visible at the right. What you described is probably how it works. If one makes changes to the rightmost measure such that it no longer fits fully in the visible window, then I certainly have no objection to shifting the music to the left and of course, maintaining the current position of the cursor. I don’t find that disorienting, and actually never even noticed that behavior.
What is happening in Dorico is something quite different, I believe. It makes giant leaps, including vertical jumps. And it seem to me the cursor position may end up somewhere completely unexpected.
At this point, I think our best path forward is to try to identify repeatable cases rather than talking in the abstract. I will be starting on a project on Monday that should provide such an opportunity, as it does not have great time pressure.
For me, there’s definitely a mouse thing. It started in Sibelius when I got the Apple Magic Mouse with a new laptop. Any application that involves horizontal scrolling jumps around with the slightest brush on its surface, sometimes after I’ve let go of the mouse for a short time - Sibelius, Adobe Illustrator, Dorico. I had a mouse-controlling program that helped for a while until it no longer was upgraded for new OS releases. I will try the mouse you’ve mentioned.
HI Pam. Just to say that since writing that post above, I’ve gone back to check it out with Sibelius and the problem has gone away there as well.
If I have an element selected and move the arrow key down to select the hairpin below it (or when I click on that dynamic), the screen jumps to the start of that hairpin. This is extremely disorienting if I’m pretty closely zoomed in and the hairpin stretches a measure back, onto the previous page.
Here’s another.
I’m in page view, in Engrave mode. I select a note partway through a flow, and switch to Write mode. I then press X to zoom out, and the screen consistently jumps to the end of the flow. Same result if I switch modes the other direction. But it does NOT make this sudden jump if Write mode is in Galley View. Both modes need to be in Page view.
Hope this is helpful… I’ve reproduced it several times now.
I cannot understand any such movement if the selected object still fits entirely within the visible window. If it extends outside the window, then I can certainly understand a HORIZONTAL shift to get it back into the window, but not a vertical shift.
To offer a perhaps silly analogy, imagine a painter working at a large canvas, full of energy, aggressively trying to get her inspiration onto that canvas with furious strokes. And then imagine a person standing behind the canvas, randomly twisting, turning, and shaking the canvas while the artist is trying to make strokes. That’s what this feels like to me.
I will take note of the comments about potential mouse hardware issues. I don’t think my problems are related to mouse activity, but I may be wrong about that. I will try to pay more attention to that.
If I have an element selected and move the arrow key down to select the hairpin below it (or when I click on that dynamic), the screen jumps to the start of that hairpin. This is extremely disorienting if I’m pretty closely zoomed in and the hairpin stretches a measure back, onto the previous page.
You shouldn’t find that Dorico does that. If the item that you’re navigating onto or selecting is even partially in view, then Dorico should in general not move the view. The exception may be for an item that spans a system break in page view: in that instance, you may find that Dorico moves to the start of the item on the first system on which it appears. If you are experiencing a case where Dorico moves to the start of an item when that item is contained completely within the current system but part of the item was in view when you started, then you should please produce a reproducible case, ideally involving both an example project and a screen recording so that we can see exactly what is where on your display.
(Apologies, Dan, but I also managed to edit your original post rather than reply to it – the perils of being a moderator.)