Change note entry to interpret white space clicks as scroll requests, not ledger note entry
Currently, clicking between staves during note entry inserts a note with many ledger lines. This is rarely intended; the user is instead probably trying to scroll the page. This violates the "Law of Least Astonishment." Such clicks should thus be treated as scroll requests, since there are other ways to enter notes with twelve ledger lines if desired. Optionally, draw the scrollable portions of the score canvas in a different color so that it is obvious where to click to move the display.
Comments
When entering notes using the mouse, this is exactly the expected behavoir, so I'm inclinded to cal this "by design". To scroll use the mouse wheel (up/down) and add the shift key (left/right)
I see. Unfortunately, on a tablet with no mouse and no keyboard, neither scroll wheel nor shift keys are available. I guess this is an example of where tablet-awareness might permit different default behavior. I still do not see that adding notes with a dozen ledger lines would ever be desirable however.
Perhaps I didn't make it clear that I was NOT referring to the normal case of clicking at a desired ledger position, where the current behavior is certainly correct, but rather to the abnormal case of clicking far away from the staff -- resulting in entry of a note far beyond the instrument's range. THOSE clicks, it seems to me, should either a) be ignored or b) cause scrolling behavior.
well, yes, making musescore more touch-screen Aware would be helpful.
But 'far away from staff' is pretty subjective, how far away should pan the score, how near should it enter a note?
Well, ideally that distance would be subject to a preferences setting; but I think we could safely pick some number of ledger lines that is beyond what anybody would reasonably want to specify by using a mouse click. Say...10 ledger lines?
Most people writing music with enormous ranges won't be using a dozen ledger lines to show those notes. And if that's REALLY the note they want, then pitch correction would still probably be used to get the right note. Mouse clicking in the middle of open space is just a UI convenience, to my thinking; and so I'd hope the system would pick the thing I'm most likely to mean. The "DWIM" (Do what I mean) principle.
This would be helpful, but the ideal solution would be to improve MuseScore's ability to scroll automatically during note entry, especially when using the vertical scrolling option.
I remember my early days with Musescore. I had this problem occasionally. But it has been years since my last mouse-entered note, it is all keyboard now.
However: So long as you use the navigator it is easy to scroll any time to anywhere, so that would be my first option. You just train yourself to point the mouse to the navigator when you need to scroll. If you have very large scores MS will work too slowly with the navigator enabled. Only then you have a problem. Or is the navigator always off on a tablet as a matter of course?
As to automatic scrolling I would turn that off if possible. I'd find it irritating to see my score move on its own while I am looking at it considering my next entry, even more so if it begins to move after a correction I made while proofreading.
I can't see how MuseScore could possibly know the difference based on what you click. The norm in published music is for staves to be close enough together that anywhere between the staves could easily be a potential note. That is, a dozen ledger lines below one staff puts it squarely on the next. Indeed, even with a score with staves as widely-spaced as My First Score - not the norm at all, except for scores with relatively little music so it comfortably fits on one page - you can only go six ledger lines above or below a staff before you cross into the next stave's territory. Maybe you are using a score with staves very abnormally widely spaced a place a dozen ledgers lines away from one staff that doesn't end up being on or near the next staff?
Shoogle: MS will never be able to provide scrolling that takes into account the position of my tablet's soft keyboard, which overlays a large chunk of the display. That is the heart of my scrolling problem. Again, this is an issue only on a keyboardless tablet. Perhaps this is too far from the normal usage case, but I have to say that touch-screen tablet use is so convenient for me that I rarely use my desktop for MS anymore.
Azumbrunn: Mouse-entry is my main option when working on a tablet without a keyboard. At my desktop, my interface choices are more normal, of course. I have not been using the navigator for score movement on my tablet to save screen real estate. However, what you say makes sense; I will try to retrain myself to use that approach, perhaps it will reduce the number of random ledger notes I add.
Marc: Ah, yes, my usage is colored by the fact that I'm usually working in a jazz lead sheet format, which has wide spaces between staves to accommodate chord symbols, lyrics, and other text. That is why I have become accustomed to "grabbing" the score in this blank space. So perhaps my usage is too abnormal to consider. However, I still think it would be advantageous to have a setting that says "don't add a clicked note further than X lines away from the staff."
Now I remember why I stopped using navigator on my tablet. The page thumbnail is so small that I cannot use it to move the currently displayed area in a useful way. Normally, I need to move the page up fairly high to bring it above my palette, inspector, etc. See attached image.
Drag the border at the top edge of the Navigator upwards to resize it.
Duh, thanks, yes. I thought this should work, but I couldn't make it happen on my tablet -- dragging is often difficult to accomplish on a touch screen, since there is no 'hover' to show the cursor change and inevitably one winds up long-clicking = right-clicking instead. But I just tried this on my desktop, and it works as intended (naturally). Depending on mouse operations can create accessibility issues for some users; but until we have a lot of tablet users I guess it doesn't matter. However, the navigator does NOT let me scroll outside the page, which is really desirable when part of the page is obscured by keyboard and palette, etc.
Added this feature request: #117331: Allow navigator to scroll above/below page
I've finally realized why it seems so natural to me to want to scroll using whitespace. I am constantly pinch-zooming on my tablet to adjust the siza/placement of the score. (Think about how you do this on your phone.) Thus if I just want to slide the page, I instinctively want to tap and drag. How about this: a long click -- I.e. a right click -- while in note entry starts a drag/scroll operation? Right click seems to have no defined meaning in note entry. It should probably do something other than add a note as if a left-click.