What's the logic with focus when entering note input mode?
I remember this was discussed at some point, but I can't find the discussion. When I write a score and switch back and forth to note entry mode, I very often loses the focus on the bars that I work on, especially if I have the continuous view on. MuseScore seems to jump to a very random place in the score if I don't have anything selected, when entering the note input mode. But it probably doesn't! It probably just follows a different logic about where to focus, when entering note input mode. I wonder what that logic is. I'd set the focus to the last item that was edited or selected before entering note input mode, whether or not the item was actually selected at time being.
Another slightly annoying behaviour is in the continuous view, where the focus sometimes jumps to what obviously is a new line, if one was in the page view mode. The cursor usually jumps, after a note or rest input, to the next beat (or half beat whatever, depending on the note value being used) and if that beat is on the first beat on next bar on next line, one loses the sight of the entered note.
Since one has chosen the continuous view, one doesn't want to lose sight of the entered note. I'd rather see that the notes that I enter stay on the middle of the screen. That way I could more easily build up block chords on the last beat in one bar, instead of having the focus jumping off that bar all the time.
This could have been sent to the feature request, but as I said, MuseScore might have a logic here that I just don't know. Hence this general discussion forum.
Comments
Nothing is ever random :-). It's simple - when you enter note input mode, note input begins with whatever you selected before entering note input mode. If you for some reason neglected select so,ething, note input begins with the top-left visible measure. Either way, if necessary, the view is repositioned to make the measure in which input begins fully visible.
So the only time you should see any jump that might lok random is if you have something selected elsewhere in your score when you begin note input. This shouldn't happen normally, though - you should always bgin note inout by selecting the locatin you wish to begin.
In reply to Nothing is ever random :-). by Marc Sabatella
"If you for some reason neglected select so,ething, note input begins with the top-left visible measure. Either way, if necessary, the view is repositioned to make the measure in which input begins fully visible."
Ok. This is the very reason to why the view feels jumpy. Of all visual measures, MuseScore selects the top left measure to be the assumed note input place. Even in the long run, this is a bad guess. Best guess would be the middle most measure on the screen. But even better a guess would be the last measure that had anything selected or done to, if MuseScore only could remember it.
I'm nagging about it, not because something is unimplemented, but because something is implemented wrongly. Someone has thought the top left bar should have the input focus, then it got implemented like that.
If it must be the top left bar, then please have the top left bar remain as the top left bar in the note input mode, too, to ensure that the measure I actually want to work on remains visible. Now the bar might suddenly jump into the right edge, when entering the note input mode, due to some quite different logics (line or page breaks perhaps).
I'm beginning to become accustomed with clicking at a measure before entering note input, but that still is an extra click that I every now and then miss. An example of where I might forget to click is if I drag something to a measure, like a crescendo or a mp, then enter the note input mode, MuseScore totally ignores that my focus was on that measure. Here I need an extra click in the measure before entering the note input mode.
In reply to "If you for some reason by jotti
To me, the question seems moot. You are supposed to click something, MuseScore should never have to guess. How on earth is museScore supposed to know where to put the cursor if you don't click? This isn't an 'extea" click, it's just common sense. And if you do make MuseScore does guess, it's going to be wrong at least half the time no matter what it guesses, so changing the guess won't really help.
As for not jumping in the case where the first measure is not fully visible, that won't be viable most of the time either - in most cases, you weant the full measure on screen. Certainly you want the cursor itself on screen!
EDIT: that said, one otimizatin might help people who for whatever reason forget to click first: we could not use the selection if it isn't on screen currently, and instead revert to top left mesure or whatever.
In reply to To me, the question seems by Marc Sabatella
This might be more about the issue of certain palette elements not leaving the note selected.
In reply to "If you for some reason by jotti
Actually, if you drag a dynamic to a measure, it remains selected, and note input will begin in that measure, so all should be well if that is indeed where you wish to begin note entry. The only time the view will shift when starting note input with something selected that is on screen is if the entire measure is not onscreen, in which case it will shift to make the whole measure (plus a slight border) fit on screen.
EDIT: OK, I stand correct - adding a palette element by double click leaves the added element selected, drag & drap does not. Maybe it should, but maybe there are reasons why it is better if it doesn't - like preserving the current selection.
FWIW, I have implemented a check to see if the selected element is currently offscreen and to clear the selection and act like nothing is selected in that case - thus starting note input with the first visible measure. Seems to work OK. If there is interest, I could submit a PR for this. It still not as good as reading the user's mind, but I don't think I can implement that, so this is the next best thing I can think of :-). Still, there is never a problem if you simply always select first like the documentation says to.