Entering note entry mode jumps me to the beginning of the score...

I'd call it neither a feature nor a bug - if you don't tell MuseScore where you wish to enter notes, how can it possibly know? It won't know what staff or what measure you wish to enter notes on. Starting at the beginning might not be ideal, but it's got to pick something. So yes, you do need to learn to tell MuseScore which staff and which measure you want before entering note entry mode, or no matter what it picks, it's bound to be wrong most of the time.

That said, it might be better to make different (but equally likely to be wrong) guess. Like, at least maybe randomly pick some staff and measure that happens to be in view at the moment.

Yes I was running foul of this "feature" earlier today.

I had to delete some notes from a score I was editing, and when I pressed N to re-enter them properly I was a little disconcerted to find I'd been sent back to the first note of the score!

I have since learnt to make sure I now select something before hitting "N" but it would be great if we could make MuseScore at least stay on the same page in these circumstances.

Just adding a 'me too'...

Hello.
I think this occur when no note is selected. may be a solution is to stay on last measure selected or modified or remember last note selected if this note exist already. I noticed that on nighly and is a bit annoying.

Robert

To be clear, this is not new behavior - MuseScore has *always* started note entry in the first measure if nothing is selected. Well, back to 1.3 and probably 1.0, anyhow; can't vouch for 0.9.6 and earlier.

What is new with 2.0 is that in 1.3, note entry would go to the first measure but you wouldn't even be able to tell that happened because the view wouldn't reposition until you started entering notes. So it would not only look like note entry was broken, but if you tried entering notes anyhow, you'd start overwriting the beginning of your score.

FWIW, the code to find the start point is in ScoreView::startNoteEntry(). As you can see, we try pretty hard to find an appropriate place to start if you've selected *something* - even something nonsensical like an articulation or a line break, or with a whole range of measures or list of notes selected. But with literally *nothing* selected, we go to the first chordrest of the score.

If we preceded all that code with a check for completely empty selection, and selected the first *visible* measure instead, that would be an improvement. This may be easier said than done, however. A reasonable compromise might be to find out what page it at the center of the current view, and take the first measure of that page.

Yes you are right when you say MuseScore do aproximately the same behaviour in 2 version

In 1.3. if note or measure is not selected the view stay in current page. Cursor is positionned at begin of score and you don"t view it. In this case you can click with mouse to add a note in the current page at a desired position and cursor is synced after.

In 2.0, cursor is positionned at begin of score like 1.3 but the view jump immediatly to the page where the cursor is. You lost immediatly the position where you plan to put the note.

Your compromise seem to be a good solution. "Take the first measure of the current page". Anyway, the view in the page should not change to avoid searching the insertion point again.

Robert

I encountered this a few weeks ago, but after wondering and an explanation from Marc, I've tried to accept it as normal behaviour.

Well, it's normal that MuseScore cannot read your mind, so there is no way it can possibly be expected to make the "right" choice if you should make the mistake of forgetting to select something. So selecting something first is always going to remain necessary to get it to do what you actually want. However, just because MuseScore cannot read your mind doesn't mean it can't make a better guess than it does now. The compromise I suggest would be easy enough to implement.

Also this: #50901: Clicking on Note Input (or N) moves focus to beginning of piece

See https://github.com/musescore/MuseScore/pull/1886

Fixed in 4c02de834e

This turned out to be more complex than I initially hoped, but I think we came up with something good. Basically, if nothing is selected, we pick the "top-left-most" note or chord that is currently in view on the page we think you care about. Even given that basic priniciple, there is a surprising amount of subjectivity in figuring out page and which note or rest that actually means. As I said, it's going to be a guessing game, and realistically, there is almost no chance we are going to guess "right", whatever that might mean to any given person at any given moment. So you'll almost certainly reject our guess and try again. But at least we will pick something on the "current" page where possible, so you are not bumped to the beginning of the score and forced to claw your way back unless you barely have any score visible at all when you press N.

The downside of "do nothing at all" is that we kind of *like* it that in a brand new score, you can just start entering notes right away. But you're right, it *was* an option :-)

No need to be sorry, improving the user experience is important to uis! And FWIW, while testing my fix, I discovered a crash - delete all measures from a score and press N. So looking into your request allowed me to find and fix that crash!

Automatically closed -- issue fixed for 2 weeks with no activity.

After happily using v1, I recently started using v2 and I am highly frustrated by this constant jump to the beginning of the score when I click on the Note Entry button.
No, I do not expect MuseScore to read my mind. I do expect Musescore to allow me to inform it where to enter the note, without unduly hindering me. Since I inform MuseScore by clicking with my mouse on my target location on the onscreen staff, the jump in screen view, which IS a new phenomenon in v2, is an extremely aggravating obstruction.

Example scenario: I'm editing an existing score, someplace in the middle. I want to clean up some overlapping notes by deleting them and re-entering them as Voice 2. I click on "N" and boom, I'm looking at the beginning of the score! Now I have to scroll around to find where I was working, so that I can see the place on the staff where I want to click in the note. (To top it off, my first Voice 2 note-click after finding my place crashes the program and I have to restart, losing work in the process; but that's a different topic.)

If it was possible in v1 to click on "N" without changing the view, it must be possible in v2. Please tell me there's a preference I can set somewhere to do that. Having to remember to click somewhere in the measure every single time I switch to Note entry mode from some other task is not a happy solution for an old bat like me.

Thanks.
Linda

It should still be the case that if you click a location before pressing "N", note input will start there. If you are encountering some special case where it is not, please start a new thread in the Support forum and attach the score you are having problems with and precise steps to reproduce the problem.

Thanks for your quick reply, Marc. But you answered a question I did not ask.

My concern is not how v2 behaves when I "click a location before pressing 'N.'" My concern is how it behaves when I DON'T make that extra click before pressing "N."

Evidently, the bottom line is: Switching to note entry from other operations in the same area of the score now requires two mouse clicks instead of one. (Click into the measure to prevent the screen from jumping away + click on the "N" button.)

I'll just have to retrain myself to do that extra click. And maybe go back to v1 for work that involves frequent switching in and out of note entry mode.

Thanks,
Linda

I'm still confused. In the current release (2.0.2), even if you *don't* click anywhere in the score, MuseScore will try to pick an appropriate place to start note input mode.

This is a huge improvement. 1.3 did *not* do this at all - it always went back to the beginning of the score. And worse than that, even though note entry went to the beginning of the score, the view did not change to the beginning, so you wouldn't see a cursor and wouldn't find out that note entry had jumped to the beginning of the score until you actually typed a note - *then* the score would jump back to the beginning. I guess if you are in the habit of entering notes by mouse instead of keyboard, you might not notice that the note entry had jumped to the first measure, but if you enter notes by keyboard or MIDI, you'd have found this very frustrating.

Anyhow, again, these bugs are fixed in the current release. If you have nothing selected, MuseScore will start note entry at a reaosnable place rather than starting note entry at the beginning of the score like it did in 1.3. And wherever the note entry cursor is, this will always be displayed, unlike 1.3, where the note input cursor would be at the beginning of the score even though the view was not showing you that at all.

Again, if you are finding some case where input is still jumping to the beginning of the score, please start a new threasd in the Support forum and attach the specific score you are having problems with and precise steps to reproduce the problem. But in my tests, note entry always does something reaosn, unlike in 1.3.

Marc, we're almost in sync. :D

Looks like this is a case of competing needs.

To you as a keyboard or MIDI user, the fact that the view did not change in v1 was a "very frustrating" "bug" and the view jump in v2 is a "huge improvement."

To me as a mouse user, the fact that the view did not change in v1 was ideal, and the view jump in v2 is a very frustrating bug.

If most MuseScore users are keyboard/MIDI people, it makes sense to force the view to jump, to make the majority happy. In that case, as I said in my last comment, the mousers will have to learn to make that extra click every time. Unfortunately, the penalty we pay for forgetting to do that every single time is pretty severe--it takes a lot longer to flounder back to the view I was looking at than it takes to go to the start of the score.

I was hoping that both camps could be accommodated, by making both view behaviors available. Hence my request in my first comment, to be able to change the view jump feature in Preferences.

Or maybe somebody can create a Mouser's View plugin to stop the screen jumps? :D

Thanks for taking the time to understand the point of view of those who've complained about this change.

Linda

I'm a mouser too, and yes, that jumping is annoying....

I'm a mouser too, and yes, that jumping is annoying....

The point is, again, MuseScore cannot read you mind about where you want note input to be if you do not take the trouble to tell it. This has been and always will be the case. It was true in 1.3, it is true in 2.0. All MuseScore can do is *guess* where you want note input to be if you make the mistaker of not telling. So in both 1.3 and 2.0, you *must* tell MuseScore where you want note input to take place or MuseScore is going tohave to guess, and depending on how its guess matches your expectation, bad things may happen. It's just that *different* bad things happen between 1.3 and 2.0. Realistically, if you don't want bad things to happen, you need to stop asking MuseScore to read you mind, and must instead get in the habit of telling MuseScore where you want note input to begin by clicking in that measure.

The bad things that happened in 1.3 were often *very* bad for people using the recommended keybaord method of entering notes, as it often resulted in people inadvertently clobbering the nbeginning of their scores by unwittingly entering notes into the first measure, not realizing that note input had begun there. That's why people requested we fix theose bugs. So now note entry stays on the current page - it does *not* jump to the beginning of the score like it used to.

So once more, if you are seeing some unusual / special case where the score *is* jumping to the beginning of the score, we need you to start a new thread in the support forum and post the precise steps to reproduce the problem. The score should *not* jump to the beginning even if you make the mistake of not telling MuseScore where you want to begin note input. It should only jump to the beginning if in fact you had selected something at the beginning.

"So now note entry stays on the current page - it does *not* jump to the beginning of the score like it used to."

Marc, I stand corrected on that point. Indeed, it often jumps to another location. This may be the perfect, intended location as far as keyboard/MIDI users are concerned. Therefore, I am not trying to report a malfunction in the program. I'm not trying to steal your "huge improvement" away from you, either. I understand its value to you. I simply asked for a Preference option or plugin option for mousers.

Because, no matter which new location the insertion point jumps to, the problem remains the same for mousers: It shifts the on-screen view along with it. This may be ideal for MIDI/keyboard users; it's a hassle for mousers.

I'm sorry that I and others have not been able to get it across that a stable ON-SCREEN VIEW is what mousers want (and had in v1) in order to efficiently tell MuseScore where to enter notes. This is a separate thing from the behavior of the insertion point, which your replies keep fixating on. And it certainly is not expecting MuseScore to read our minds (which got rather offensive by the fifth or sixth repetition).

@Jojo-Schmitz I just started using your Note Name plugin. Love it! Since you understand the mousely workflow, any chance you could develop a Mouser View plugin for v2 to prevent the view jump?

Linda

Thanks for clarifying and for confirming the score is *not* jumping to the beginning. I'm sorry you found my replies offensive, but I was honestly confused, because what you were describing simply did not match what I actually see to be the case, and I could not figure nout where the disconnect was.

So, what you are actually seeing is not a jump to the beginning, but rather the slight shift that comes from MuseScore first guessing what measure you want, then starting note input there, and then slightly adjusting the view so that the chosen measure is fully visible on screen if it wasn't already. If the chosen measure is already fully on screen, there is no shift.

So again, you can avoid this simply by clicking a measure that is fully visible on screen first. As far as I know, clicking a measure first has *always* been the officially correct way to start note input, so I don't why see why doing so should be considered a hardship.

And FWIW, this is *not* a separate thing from the insertion point (cursor). Whether you intend to use the keyboard or not, the cursor is *always* relevant in note input mode. It affects the behavior not just of the keyboard input, but also toolbar and palette icons. Not having the cursor visible when in note input mode is a bug, pure and simple. It means that after entering note input mode, clicking a toolbar icon like the "#" sign would also end up having an apparently random effect, altering some note you can't even see and would have no way of knowing you had altered until it was too late. An option to re-introduce that bug would *not* be a good thing.

BTW, there is no way a plugin could change the behavior of the score view. the only way to re-introduce the bug where the cursor would sometimes be offscreen is to change the code itself.

I am not a 'mouser' but I am a programmer (and a MuseScore user); I tested the current released version behaviour on this aspect on a 4-page score with 3 systems of 5 parts each in each page, by:

• clicking on nowhere on the first page (to ensure that nothing is selected),
• scrolling with the mouse to another point of the score,
• clicking the [N] button (I assume this mimicks reasonably well the workflow of a 'mouser')

and discover the following:

1. if I scroll to have the top of another page in the top left corner of the view, note entry begins at the first note of the first part of the first system of the page, with no view change
2. if I scroll to have the beginning of the top of the second system of a page in the top left corner of the view, note entry begins at the first note of the first voice of that system, again with no view change
3. if I scroll to have the beginning of the second part of the second system in the top left corner of the view, note entry begins at the first note of that part and the view moves to have the full system in view
4. if I scroll to have a mid-system point of the second part of the second system in the top left corner of the view, note entry begins at the first note in sight of that part of that system and the view change to show the full system from the beginning.

In summary:
I) In all cases, note entry begins at the first note currently in sight, which is the best guess I can imagine in absence of any selection.
II) If that note is mid-context, the entry point does not move, but the view moves to provide a reasonable context.

A) What of this behaviour does not match your needs?
and
B) How it should be modified in order to match them?

Thanks, M.

Hi, Miwarre.
Thanks for going through these steps.

In all your examples, the target note ended up still in view on the screen after pressing N.

If that were my experience, my answer to A) would be: Not much, except for having to re-orient my eyes to the shift in on-screen position, to find my target note. This takes a bit of thinking when I'm trying to add notes in a score that's already populated. (Not a big deal; but that disruption to my thought process was happily unnecessary in v1.)

But that was not my experience. I'm attaching a Word file with screen shots to show how my screen view completely changed when I pressed N.

Yes, it often took the insertion point to a note in the vicinity of the first measure that had been on my screen. Unfortunately, it also shifted the display to the group of measures ahead of that measure, with the new insertion point being the last note displayed at the far right of the screen instead of the first note on the far left. The result is that ALL the notes I had been looking at have shifted off-screen.

As you can see from the last before/after pair of screenshots, the display sometimes shifts far away, not just to the beginning of the first displayed measure. That's what was driving me nuts last night; it kept shifting me from the coda to the beginning of the score, over and over. And when I tried to click and drag the score to the right view, I ended up entering bogus notes in random places, until I wised up and opened Navigator.

I'm guessing that I must have left something highlighted in the opening measures before I panned over to the coda during playback and subsequently clicked on N. Having a highlighted item elsewhere in the score would not have affected my screen view when I pressed N in v1, but obviously it does in v2. Very aggravating to have to re-find what I had been looking at, after that big jump happens.

The good news is, your experiment suggests that v2's behavior might work better for me in Page View. I've been working on my current score in Continuous view, to help avoid inadvertently altering the wrong one of two similar staves (which I did not hide because I was referring to it).

And, if the cause of the quantum leaps is indeed a still-highlighted element in a previously edited portion of the score, retraining myself to pre-click into my target measure should take care of that.

To answer your Question B: I don't want MuseScore to slam the keyboard/MIDI guys by going back to the old way for everyone. Rather, I'd hoped to get the non-jumping screen view (like in v1) as an option somehow for mousers. If that isn't feasible, perhaps you can adjust the view jump in Continuous view to display the full measure including the new insertion point plus the measures after it, not ahead of it.

Beyond that, this old dog will just have to learn the new tricks. No matter how frustrating that is at times, it's a whole lot easier and better than Finale!!

Thanks very much for looking into it.
Linda

I think that discovering that your observations apply to Continuous View might explain many things. The first screen-shot pair is interesting:

The note from which the entry cursor starts is probably the first note actually displayed, except that it is obscured by the clef/key/time overlay of the continuous view. Also, the attempt to provide a context for note entry is baffled by the very nature of this type of view: there is no obvious structural point (like systems in page view) to use.

Possibly there is room for improvement of this specific detail in continuous view.

However, a few questions: at the very beginning of your text you say: "I want to add a note to the final “God” in the coda." How MuseScore can possibly guess this? The point you refer to is at the end of the screen. And in which of the three staves you want to add a note?

Lastly, if some note is selected somewhere else in the score, MuseScore using it as entry starting point perfectly suits, for instance, my work-flow (as an opinionated 'keyboarder'), but seems ill-suited to yours. Should MuseScore prefer the current view position to the current selected element to position the entry cursor, your needs were possibly better served, but mine would be disarrayed. Of course, my needs are not more important than yours as yours are not more important than mine. But a decision has to be made in one sense or another and someone will remain unsatisfied.

Even an apparently "minor" point like this (as it is currently classified) may end up raising fundamental design choices. So, improvements should always be welcomed, but they should be planned with as much care as possible and with an eye on consequences as wide as possible (which not always happened in the past, but hopefully we are learning...).

The document with the screenshots emphasizes the importance of including actual examples, so thank you for that. For one thing, until now it had not been apparent at all we were talking about continuous View (which didn't even exist in 1.3), so any changes we made that affected Page View only awould not have made a difference. I can also now guess that the problem wasn't that *nothing* was selected, but that *something* was selected, but the selected element was on a different page. So any changes we made to the behavior when nothing is selected would not have made any difference in these cases either.

Anyhow, again, I would ask that if this conversation is to continue productively, that we do so in the Support forum. An already-closed issue is not a good place for discussion of such topics - it should be in the forum where others can see and participate in the discussion.

Hi again.

I forgot to mention before, I'm not savvy enough with html tags to apply bold formatting to phrases, so I'm using caps for emphasis. Not shouting.

"However, a few questions: at the very beginning of your text you say: "I want to add a note to the final “God” in the coda." How MuseScore can possibly guess this? "

Guys, it doesn't need to.

Unlike the keyboard/MIDI user, the mouser can indicate the exact location of the note (its location within the score and its pitch) with a single click onto the staff.

Therefore, WHEN THE DISPLAY STAYS PUT (as in v1), there is no need for MuseScore to know my intentions before I press N. MuseScore doesn't have to "guess" anything, because it doesn't have to DO anything at that point. It just has to sit there until my mouse-click deposits the exact note, or # or whatever, onto my exact chosen location on the staff. That one mouse-click after pressing N tells MuseScore all it needs to know.

Of course, that situation changed when MuseScore was programmed to display a defined location when N is pressed. Now, it needs to know the location, in order to do what it now needs to do.

Oh, shoot. Just saw Marc's advice to move this to the support forum. If you see a need to continue the discussion, would you please do that? I'm not sure how to.

Thanks.
Linda

There is no way to move threads. That's why my advice was to start a new discussion on the forum. Fwiw, you might want to re-read my response #28 first - it explains why the old behavior is a serious bug regardless of whether one uses the mouse or other input methods. I'm not saying there aren't other possible solutions worth discussing (on the forum!), just that it isn't nearly as simple as you are thinking it is.