Replacing a note with an accidental leaves accidental on new note

I don't see this in note input mode, at least not in 3.3.4 (but I don't think that changed). But I can confirm in normal mode. Same basic issue as Shift+letter that we discussed earlier. Maybe all entry of notes by typing a letter from normal mode should ignore the toolbar accidental, since it is relevant to the current note.

I'm sorry, there is no toolbar operation involved here. No toolbar accidental was selected.

Well, yes there was, because the toolbar accidental selects itself when navigating, just like the duration buttons do. They show you the duration and pitch of the current note. So just as typing "D" with an eighth note selected enters an eighth note because eighth note is what is selected on the toolbar when you selected the note, so typing "D" with a sharped note selected enters a D#, because sharp is what is selected on the toolbar when you selected the note. Somehow the first seems expected and the second doesn't even though it's the same concept, so I'd recommend we ignore the accidental state on the toolbar when entering a pitch form normal mode.

I see. That's a funny one! "And then the bartender says, 'no, but take my wife', and the camel died!" Haha. I see now. Yes, that should be the fix.

See https://github.com/musescore/MuseScore/pull/5516. With this fix, the old accidental is not applied to the new note, and it does not matter whether or not the Shift key is used.

What will happen if you explicitely click the accidental before entering the new note?

I imagine it would work, but that's nothing but a work-around. A fix has been checked in now.

No, I mean after the fix, if you really want to have an accidental for the new note, will it be ignored?

If you really want to have an accidental for the new note, press N first, and select the accidental that you want before entering the note.

What I would do if it were fixed is type the new note and raise or lower it with arrow keys.

I'm not sure this is the right fix.

The code change that I have proposed is good. It moves a line of code to the proper place, and removes duplicate code. What could possibly be wrong with that?

The recommended way to enter a note with an accidental is to begin note input mode, select the accidental, and then enter the note. However, I understand that people are used to the old behavior. I'm not sure whether we want an "apply input state" command or 5 new commands: "apply sharp", "apply flat", "apply double sharp", "apply double flat", and "apply natural", but I lean towards the latter.

That's not a problem. Courtesy accidentals and doubles are rare enough, and keeping the accidental from a note not at the octave is always wrong; it is orthogonal to the thing being fixed. What I just described is what I had been doing all along.

This fix is about neither case; it is about entering a note with NO accidental and getting one, as it were, by accident.

The accidental button is pressed on the toolbar, which should mean that entering a note will apply the accidental to that note.

That is true only in note input mode. This issue is about entering a note from normal mode.

Where is the inconsistency? Is it about the accidental buttons behaving one way in note input mode and another way in normal mode? Because that really does make sense -- at least it does to me.

Fixed in branch master, commit 05ed180bc6

_fix #298115: Replacing a note with an accidental leaves accidental on new note

Resolves: https://musescore.org/en/node/298115.

This makes sure that ScoreView::startNoteEntry() clears the accidental state. Since this function already properly sets the duration and rest states, none of this needs to happen directly from within ScoreView::cmd()._

Fixed in branch master, commit 8d75b32e75

_Merge pull request #5516 from mattmcclinch/298115-start-note-entry

fix #298115: Replacing a note with an accidental leaves accidental on new note_

So you did an end-around and bi-passed Anatoly

I am not sure I understand what you mean. If you did not want this fixed, then why create the issue report?

I did nothing of the sort.

Hey, I voted for it.

I still don't understand why you do not agree with my solution. What is there even to disagree about? Do you even understand why it behaved the way it did and why my fix works?

It now works the way it should have done from the start. That is, it now behaves the way I originally intended when I implemented the new note input workflow.

I am also not sure what the disagreement is about, but for the record, I also thought this was the correct solution and what should have been implemented from the start. This was discussed on forums, in the issue tracker, and on Telegram, and there was pretty widespread agreement. I don't even recall there being any other solutions proposed, and it's kind of hard for me to imagine what an alternative solution would even look like. Either we honor the accidental state - in which case we have the problem described in this issue - or we don't, in which case we have the fix that was implemented.

I have pushed this fix because it seemed completely logical to me. In normal mode accidental buttons state refers to the currently selected note (this is exactly what allows toggling accidentals for selected notes), and in note input mode it refers to the note which is about to be entered (which allows entering a note with correct accidentals right away and makes mouse input more intuitive). There seem to be no conceptual reasons why accidental buttons should apply to the note which is being added in normal mode. The proposed patch also does not really add any special handling for this case but just makes things more logical and consistent in the code. So I did not think of any issues that could possibly arise from this fix, although I did not read the full thread and thus missed possible objections, sorry for that!

As far as I understand, the main objection about this fix is that it does not allow something like "double-sharp shortcut"+"note name shortcut" work the same way as it would if entering Note input mode first. Still I would admit that such shortcuts usage wouldn't work consistently even without this fix, as:
1) Accidental shortcuts work as toggles on the currently selected notes (if any) in normal mode, so attempting to press "accidental shortcut"+"Shift+letter" to add a note with accidental to a current chord will alter the existing note accidental, which is unlikely to be expected and which wouldn't happen in note input mode;
2) If a note already has this accidental, pressing an accidental shortcut would actually turn it off so this shortcuts sequence wouldn't be reliable for replacing notes;
3) If one does not press an accidental shortcut and presses a note name shortcut while a note with accidental is selected, that accidental would be added to the new note (which is exactly what the initial bug report mentions here).

The first issue actually contains contradicting requirements: accidental state should apply to the existing note (from the "normal" mode paradigm) and to the new note (if that shortcut sequence is supposed to work), but not to both of them (as user probably intends to either alter the first note or apply accidental to the second one, not both). So resolving it in a consistent way would require changing something more fundamental like splitting accidental shortcuts to those modifying the existing or new notes, or forbidding to add notes while being out of note input mode at all. However I don't believe that this issue alone is serious enough to require such changes, although adding extra shortcuts which would always apply accidentals to existing notes might indeed be reasonable to consider. It looks like #297458: Feature Request: New set of shortcut commands to "apply" accidentals in note-entry is exactly about that. Otherwise the proposed pull request and a recommendation to enter note input mode for adding accidentals to new notes is the most reasonable solution here.

Hope this clear the confusion, and sorry again for not noticing this discussion before applying a fix.

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