Can't always see where current note entry position is
1) create a new blank score (single staff is fine)
2) enter a couple of notes in the first measure using step entry
3) exit note-input mode (e.g. "Esc" key)
4) click on an empty measure later in the piece
5) clear the selection (Esc key again)
6) observe that nothing is selected, nor is there any indication of where the current note entry position is
7) type a key A-G to enter a note
8) the last note you entered in step 2 gets modified
9) type Esc, zoom/pan such that this note isn't visible
10) click on an empty measure then type Esc key again
11) type a key A-G to enter a note
12) note gets created in some random position that happens to be visible (seems to be at the start of the first visible system?)
Expected: probably, a note being entered at the measure you had just selected, but at any rate, it should be readily predictable based on what you can see what will happen.
(NB: see below, but in current v4, the behaviour is somewhat different)
Comments
Over the years there has been a lot of refined to where notes go in the special case where you make the mistake of forgetting to select a location first. The current algorithm is the result of many discussions and consensus among many people. I wouldn't be in a hurry to change it without a lot more discussion from users and input from Martin, after careful review of all the discussions that led to the current system to be sure not to repeat any older mistakes.
The basic idea is to reconcile two conflicting desires in those special cases where you make the mistake of selecting a location. Some people do expect - and have voice this opinion strongly - that entry should go wherever they last entered music, because "of course" their intent was to continue where they left off. Others are equally vocal that entry should always go to someplace currently visible, because "of course" they intend to be entered music in the place they are actually looking at.
So what you try to do is favor the last-used position if it does happen to be visible, otherwise, choose something visible - top left visible measure because, why not, makes sense in the case of looking at an empty page.
No doubt there is still room for further tweaks in the corner cases, but it is important not to throw out years of refinement and consensus in the process.
In reply to Over the years there has… by Marc Sabatella
Well the obvious solution to me is that if nothing is selected there should be some other marker indicating where the current note entry position is (this should probably double as the current playback position too). After all when editing a document in a word processor you always know where the cursor is.
But I'd also expect that selecting a measure (or any range) would always make its first note/rest the new entry point - after all it is if you don't deselect first, and it is if you just select a single note/rest (even if you then deselect). So why would deselecting a measure seemingly change the entry location back to wherever you were before? *
As for what should happen if the current entry position is out of view, then I would 100% expect it to bring that back into view, and that's exactly what happens if you are still in entry mode already or a selection is made. The only issues occur currently because you can't see where the cursor is if no selection is made and not already in entry mode.
* From what I can discern the logic is:
a) if I select an individual note/rest, that becomes the new note entry location, and remains that way even if I deselect it
b) if I select a range, it doesn't change the note entry location, unless it's still selected at the point I try to enter a note, at which point the beginning of the range becomes the new location. If it's not selected, the note entry location is still wherever it was when you last left off (unless it's out of view).
What I forgot to do is check is what it's doing in the current v4 (pre-alpha) version, and it seems it's quite different now - in fact it seems to simply starts note entry at the beginning of the piece in all cases where there's no selection (whether or not it was in view or not, but it does get scrolled into view).
In other words the differences are:
8) v3 - the last note you entered in step 2 gets modified, v4 - the first note you entered in step 2 gets modified (in fact the note you enter is always placed at the beginning of the very first measure of the top staff)
12) v3 - appears to pick some first visible position to insert note, v4 - again, the note is entered at the beginning of the top staff (which is scrolled into view).
I don't think this behaviour is great either, but at least it's more predictable than v3.
It's a bit surprising that the behaviour is so different actually as the function that does this has a comment saying "copied from ScoreView" (ScoreView is part of the v3 codebase, no longer exists in v4).
In reply to What I forgot to do is check… by Dylan Nicholson1
The solution you have proposed seems the most correct one, always display some kind of cursor even if nothing is selected.
Going back to note entry mode must put a note there and scroll it in view if necessary.
Unselect all must unselect all but keep the cursor where it is.
I'm actually still kinda puzzled about how works in v3, as it seems ONLY for the default score that gets opened when you first start up the application (assuming you cancel the Start Center window if you have it showing by default), note entry via the keyboard doesn't work at all initially. If you select a range (e.g. a measure) and deselect it, no difference - the A-G keys still do nothing. But as soon as you select an individual rest then deselect (via Esc, or whatever), and try again (press a key from A-G), it now puts a note at the rest you just selected. Once you've done that there's no way to get back to the state of keyboard note entry not working at all other than restarting MuseScore (creating a new score won't work, because when you create new score it automatically selects the first rest which appears to initialize the note entry position).
I still think it's very odd that after exiting note entry mode and having no selection, using a key A-G to restart note entry replaces the last note you just entered (as I just noted, v4 doesn't do this).
In reply to Well the obvious solution to… by Dylan Nicholson1
When you aren't in note input mode, there is no cursor. At most there is a selection, but it's not necessarily a single point - could be a list or a range.
I guess showing some faint outline of the note input cursor even when note input mode could be potentially nice. But I don't see that it addresses the issue at hand in the cases where the previous input location is no longer in view - I would definitely be opposed to changing the cursor to whatever happens to be in view -what if the intent was to return to previous location, and then you'd be upset to find your cursor lost. So it's still likely to be the case that sometimes, the cursor is not in view, and I fail to see how that's a problem.
Inventing whole new model of how to handle the cursor outside of note input mode, just to solve the corner case of a slight possibility of user surprise in the situations where they make the mistake of forgetting to make a selection before starting note input mode and for whatever reason don't find the default guesses to be useful, seems like over-engineering to a pretty extreme degree. But, it could certainly be an interesting forum discussion. Maybe some sort of consensus might develop as to what it might mean and how it could be exploited beyond just this corner case of handling a particular type of user error.
In current versions, we rely on there having one been a selection,. if there was literally never a selection then we don't recover well from theaat particular user error of entering note input without first making a selection. but if there was a previous selection, we can use that. Still, it's important to recognize this is a corner c are error. users should never enter note input mode without making a selection. I'd be happy to just throwing up a dialog - "sorry, please say where you want to start inputting notes before trying enter them!".
Comparisons to word processors aren't really appropriate here. In a word processor, you're always in note input mode. Of course you can type a letter without entering "letter input mode", because "letter input mode" is all there is. So of course you always see a cursor.
A better analogy is a graphics editing program. Open a picture in Photoshop and see what happens if you start typing. Nothing, I'm guessing, unless you first add a text box (I dobn't have that program myself, but certainly other graphics programs I know work that way).
It's been proposed that we find a way to do away with note input mode and somehow reinvent the interface to always accept input directly. I could imagine such a radical redesign, but that's far bigger discussion than just these corner cases.
In reply to In current versions, we rely… by Marc Sabatella
Nobody has asked to change the position of the cursor because no more in view.
There would absolutely be no change in how the program would behave when a selection exists.
The only difference would be what the code is currently doing when there is no previous position because of ESC : Insert note there if visible otherwise insert at first visible measure, that was quite smart but surprising and therefore not ideal even if the results of long discussions.
And why these long discussions ? Just because there was no cursor shown of where the position was. Would we have one, nobody would discuss the logic to restart note intput there.
And stop calling going into note entry mode after escaping the selection a user error, it isn't and if really it was the program should display an error message (but there is no error and rightly so).
In reply to In current versions, we rely… by Marc Sabatella
My understanding is certainly that @Tantacrul's preference is that you should never need to explicitly activate "note input mode". In principle you don't need it at all - you just need to be able to see the input cursor, which may be at the currently selected note/rest, or just after it, and able to remain there even if the selection is cleared.
I would actually say editing music notation is arguably more like word processing than general purpose graphics editing, though it really is fairly unique in many regards.
At any rate, re-implementing version 3's behavior in v4 would not be trivial so it makes sense to agree on whether it's really what's wanted first.
> There would absolutely be no change in how the program would behave when a selection exists.
That's not at all clear to me from this discussion. The very title of this thread suggests a proposal that the note input be always visible. That to me makes it sound like if you scroll the score and the current position is no longer in view, then the note input position would be changed to be something in view. There have been enough other thoughts offered but no real solid specific proposal, so I can't tell if the title is just misleading or what. But anyhow, there definitely has been a suggestion of a change.
The idea that the current selection still be honored even though out of view is exactly what people complained about a few years ago when that's what we did. They said things like "the fact I might have made a selection previously and then forgotten about shouldn't force note input to go somewhere other than the part of the score I am looking at right now - it's what I'm looking at I am clearly interested in". I can't recall a single person disagreeing with that sentiment. This is why the behavior was changed to ignore the current selection when out of view. To me, honoring actual expressed consensus of users is a better way to guide design than some abstract principle.
In reply to > There would absolutely be… by Marc Sabatella
Then what's need to be done is pretty clear: in case of no selection, display the virtual cursor in the first visible measure where the note input would start. That would reconciliate the user need expressed some years ago that you have explained and the no surprise that is the basic of any well behaved software.
And certainly align V4 behaviour with that as the current one is certainly not logic neither in your eyes in the ones of the OP
In reply to > There would absolutely be… by Marc Sabatella
I certainly don't think the input cursor should automatically move to whatever position is visible as you zoom/pan any more than I'd expect that behaviour editing a text document (or a MuseScore forum comment!). By "always visible" I only meant "visible if its position is within the current viewport".
If I zoom/pan around so it's off screen then start entering notes I absolutely expect the notes to be entered where the cursor position had been shown (which should then scroll back into view), as happens now in all cases except when you've left edit mode and there's no selection. You can try this yourself: start entering notes, then use PgDn /PgUp or your middle mouse wheel etc. to scroll the note you just entered out of view, then enter another one. As expected, it scrolls the input cursor position back into view and adds the note there. So if the cursor remained visible after exiting "note input mode" (which is necessary if you don't want clicking on the score to add new notes!), then I'd expect the same behaviour if I scrolled it out of view then started entering notes again.
Btw as I noted, in v3 currently, the new note entry position if there's no selection is not actually the top/left-most position in the current viewport (which might be part way through a measure), in fact the more I experiment with it the less I understand what on earth it's doing - in many cases it does in fact scroll back to the very first measure (for the staff that is topmost in the viewport). It seems to depend considerably on where the note entry cursor had been previously (but is no longer shown after leaving note entry mode then subsequently scrolled out of view).
After 20 minutes of trying I couldn't figure out what it was doing at all, so I finally resorted to looking at the code.
There's a comment in the code for ScoreView::startNoteEntry saying:
It's the "favor top left quadrant if possible" part that results in some quite unpredictable behaviour.
Basically, if there's no current selection, it picks 5 points within the current viewport
1) the exact centre of the top-left quadrant
2) the top-left
3) the bottom-left
4) the top-right
5) the top-bottom
Then checks each one in turn until it can find one such point that can be mapped to a particular page. That page is then the one on which the note will be entered (!). So if your viewport shows multiple pages, then if there's page under a point 25% of the way along the top and 25% of the way down the left side then that's the page that's used.
If your viewport doesn't have any pages under any of those points, note entry won't occur at all.
But assuming it's found such a page, it loops all notes/rests on it finding the top-left visible one, but stopping if it first finds the position of the previously selected individual note/rest. Whatever it finds is then selected, and used for where the note entry occurs.
This can cause some quite bizarre outcomes - e.g. if the note you'd previously entered happens to be just off the top of the viewport, but the first rest in that staff is within the viewport, it will try to add the note there, even though the newly added note is most likely off the top of the viewport too (given the current octave means new notes are added above the staff).
The other thing that keeps throwing me is that if you accidentally click on a measure to drag/pan the score, then start note entry mode, it starts at the beginning of the measure you clicked on. I generally agree this behaviour does actually make sense but when just trying to pan "experimentally" as it were, such that I wasn't actually looking at where I initially clicked and started dragging (hence didn't notice I'd selected a measure), it still surprised me.
BTW I have no idea how any of this behaves using a MIDI keyboard to enter notes, I don't actually have one to hook up currently. But I will say this behaviour would be super unexpected if you happen to accidentally hit a key on your midi keyboard!
Again, note that NONE of this logic exists in v4 at this point.
Should it?
Playing keys on a MIDI keyboard doesn't trigger an automatic entry into note input mode, so that's a non-issue. This behavior has nothing to do with entering notes per se, it's about the enabling of note input mode. Whether you do it implicitly by typing a note name or explicitly by pressing "N", we need to choose a location. It's about choosing a location in the specific cases where the user makes the error of failing to do so.
So again, no doubt there are corner cases not being handled ideally. But I'd like to think the basic consensus that developed over the course of the last decade or so is not being challenged:
1) In the case where the user correctly selects a new input location and then enters not input mode, that selection should be honored whether it happens to be on-screen or not.
2) In the cases where a user makes the mistake of failing to select a new input location first, we should forgive the user and attempt to choose a location for him or her. There are really only two logical choices - only two choices I have ever heard a user requesting or that seem like they could make sense any intuitive sense. Those two choices are a) "wherever note input last left off" or b) "something currently in view". In cases where the place note input last left off also happens to still be in view, these are not in conflict, so it's a no-brainer. But if the place where note input last left off is not in view (and, again, where the user made the error of forgetting to make a selection first), this is the only possible case where there is possible debate.
The current behavior here is to pick something currently in view - again, based on user feedback over several years. If someone is arguing that we should negate the feedback and do something else instead, fine, but I urge that person to actually go back to the forum and get more feedback before changing someone people generally have agreed is what they wanted.
But if it's just about tweaking the algorithm to choose a different location in this particular error case, that's fine, I don't think additional feedback would be required before tweaking that algorithm.
If someone wants to argue it would be helpful to show some sort of visible marker of "the place where we'd select for you, should you make the error of entering note input mode without selecting a new location first", I guess I wouldn't really complain as long as it was toggleable and defaulted to off. After all, why should I want to be burdened with a more cluttered display, showing me a location I'll hopefully never use? Normally I don't make the mistake of forgetting to select a location first, and even if I did make that mistake, chances are I'd also forget to scan the window to notice where that new marker was. So I'd still need to do the same thing I'd need to do now: look around (perhaps at the status bar) to get my bearings if for some reason I'm confused.
Only if the entire user interface were designed to make that an actual manipulatable cursor - thus, more like a text editor - would constantly showing this location make sense. And then we'd need a whole new set of commands for manipulating this cursor position as something distinct from the selection, and furthermore come up with accessibility behavior (how to switch by keyboard alone between changing selection vs moving cursor, what the screenreader reads, etc).
So I come back to what I said to begin with: if such a radical redesign is being proposed, that's definitely a conversation worth having, but t's an enormous discussion that absolutely should not just be taking place between a small handful of developers on the issue tracker. It needs professional design input, formal designs, usability studies etc. It's a monumental task, could be worth it, but it's a totally different subject.
In reply to Playing keys on a MIDI… by Marc Sabatella
I'm not proposing anything radical, just noting that it would be quite a lot of work to reimplement the v3 behaviour in v4, so if there are improvements/ simplifications to be made, now's a good time.
I personally find the v3 behavior very unpredictable and surprising, but if whoever coded it up originally is happy to port it to v4 they're welcome to.
Btw I certainly don't agree that trying to start note entry mode without explicitly choosing a location first is a "mistake" any more than trying to start typing into a text document without choosing a location first is one.
As for the visual clutter of a cursor, does that bother you when editing text? I would expect it to be something very subtle at any rate, and could serve the dual purpose of letting you know where note entry AND playback will start, both of which are unpredictable currently (I haven't checked out the code for the latter, but it's certainly not the same. The bigger problem is that in many cases, e.g. just after entering a series of notes , you logically would want the playback cursor to be at the beginning of the passage while the note entry cursor should be at the end. So I suspect two cursors are needed but much of the time they'd be in the same place)
I agree the algorithm to detect the top corner of the visible screen is often unpredictable, and I see nothing wrong with simplifying that. Are you now saying that's all you are proposing? Or are you saying the basic breakdown I gave above no longer applies - that there are cases where a valid selection is ignored? if so, that's a critical bug, absolutely must be fixed. If it's just about what happens in the case where the user makes the error of forgetting to select anything at all, I can't say I care much at all about exactly which place within the visible windows gets selected. I do know, however, that there will be users who will be disappointed if we no longer can honor the last known note input position in those cases where it does happen to be on screen.
As for visual clutter, with text, again, the cursor is always there, and it's the only thing always there other than the text itself - no additional concept of a "selected note/rest" that serves as the main point of focus for things like the navigation keys, Inspector, status line display, or screenreader feedback. So again, if we somehow move to a "one cursor" sort of model, that could be interesting indeed. But as it is, having two apparent cursors visible at all times, with unclear semantics as to how they relate or how to independently control them - seems like a recipe for extreme confusion. Showing a third potentially conflicting cursor for playback is adding insult to injury.
Again, a coherent plan to redesign the basic use model of the program to actually work from a single cursor more like text - that's a totally separate topic and a huge discussion very much worth having.
But cramming additional clutter into the UI and dealing with the resulting confusion just to maybe in some unspecified way help in the case of a hypothetical user who makes the mistake of forgetting to select something before entering note input mode (but somehow is assumed to constantly monitor the location of the new input cursor?) seems like a big step in the wrong direction. If we're that concerned about users who make the error of forgetting to select something before entering note input mode, why not just pop up an error dialog that says, "sorry, you need to select a location first"? Seems a much simpler solution to a mostly non-existent problem. But I prefer the current behavior, where we at least forgive the error and try to do something reasonable, without inconveniencing normal use of the program in any way.
In reply to I agree the algorithm to… by Marc Sabatella
No, I think the behavior of picking some location that happens to be currently visible isn't justified at all personally as it's almost never going to be exactly what the user wanted. I'd like to know of any of other software that does the equivalent.
Anyway I've raised an issue in the github issue tracker for consideration to be given toward improving the v4 behavior (which as I said, currently always returns to the very first note in the piece, usually the top staff but not always).
I don't know any software that does the equivalent. I just know it was a commonly and very loudly requested feature over the years, taking it away without good reason is not likely to sit well.