Feature Request: New set of shortcut commands to "apply" accidentals in note-entry

• Nov 21, 2019 - 23:51
Reported version
S5 - Suggestion

After noticing that accidental placement post-note-entry while in "Note Entry" has been removed in favor of 'preparation' like with duration settings and augmentations #297455: Note Input: Sharp/Flat/Etc in Note Entry is disabled now in 3.3, this request is to provide an alternative set of functions for [double flat/flat/natural/sharp/doublesharp] that will apply to the currently selected note while in note-entry.

Application of these already exists while not in note-entry (this behavior wasn't changed at all), so if these were implemented, it would be appropriate to specifically label them not merely as "apply" but also in reference to "Note Entry:", like ["Note Entry: Apply [x] Accidental"] or something more reasonable.

This way, not only would be maintained the logical relation between duration/augmentation/accidentals as "preparatory" in the current default behavior, but also the 'old way' of being able to provide accidentals afterwards would still be able to be performed if the user were inclined to define these shortcuts, or choose one over the other by using only one particular set of shortcuts.

Can't think of a reason not to include these alternative versions, so it would seem to be a decent side-implementation for those who would like to be able to do so.


Slightly echoing what "Steve-Blower" wrote in the other thread post:

Personally, when I read in notation "D-Sharp", I don't like having to implement this backwards as: "Set #" and then "D", but would rather maintain the same linearity of D# with entering: "D" and then "#".

Frequency Once Many
Regression No Yes

Indeed. Furthermore, it’s very uncommon to need the same accidental multiple times, so the toggling on/off actually results in many more keypresses being needed to enter a score ☹

In reply to by mirabilos

The toggling doesn't actually 'stick' though, right? Like, if the user presses [sharp] and then inserts a note, the next note to be entered doesn't retain the toggle, so it shouldn't be too much of a problem. Still, post-application of accidentals during note entry really should be an option to the user and not something removed without exception, especially after all this time of being able to do so and more than likely being adapted to that style of functionality.

WW's right about the toggle though there is an added benefit. If there is an accidental on a note, the toolbar button will be pressed. To get rid of it, click the button (or use your shortcut) and the accidental and the accidental will go away, hence the toggle. I find this easier than trying to click the accidental and press delete.

In reply to by mike320

Another "crucial" reason to include this functionality or to 'knock' the new way is that when building chords, Musescore allows for using "add intervals" rather than add "A-G". So, the user can insert a C and then for example use the shortcut for "Add 3rd" and will get an E. The problem here is that if the user inserts the C, then "sharpens", but then uses the "Add 3rd", the third won't get the sharp! And the user has no way to add the sharp afterwards while in note-entry! The old way did allow for this of course by sharpening afterwards quickly. So he who uses interval chord building in this regard is out of luck as it currently is in 3.3.2.

In reply to by worldwideweary

Nor an explicit courtesy accidental.

But that’s the other argument, for deletion, removing is something different from naturalising the note… the old behaviour might be slightly less intuitive if one doesn’t know it, but much more once learnt, especially given that it’s also in the order one normally thinks of notes (base note first, then accidental), and the order in which notes are read (yes, the accidental is placed in front, but one still goes to the notehead first with the eyes).

FWIW, I support the request totally, it would help those of us accustomed to the old way while costing nothing but a few lines of code. Although since there are already palette items for this, I'd still love to see the ability to assign shortcuts to arbitrary palette items, which solves the problem without the need for new special commands - but is of course a far bigger project.

That said, it's also important to look at the issues raised and see if they can't be dealt with individually within the current system.

First, I am confused by the comment about "the toggling on/off actually results in many more keypresses being needed to enter a score". As mentioned, the toggle turns itself off upon entry, so I can't see any respect in which this statement is actually true. Can someone give a specific example?

While it's true that Alt+number to add interval doesn't currently honor the accidental state, I'd consider that just a bug to be fixed, not an inherent weakness in the design.

Similarly for a concern raised elsewhere that it is now more difficult to enter a courtesy accidental on a note that is a fifth or more away from the previous note, as typing the letter name enters the note in the wrong octave and requires Ctrl+Up/Down after entering the note, and that currently loses the courtesy accidental. That's a problem right now, but easily solved by changing Ctrl+Up/Down to preserved user accidentals (either always, or just for single selections, or just in note input mode).

As for concerns about us saying "D sharp" out loud making it more "natural" to enter it that way, OK, but as noted, we write it with the sharp sign in front of the note, so it's hard to make a convincing argument that one is inherently more natural than the other. There's no getting around the fact that the way we express notation is inconsistent, so either order of entry is natural in one respect and unnatural. To me the tie-breaker in favor of the new system is not having to hear the wrong pitch first. But again, I agree it's worth having both methods available.

In reply to by Marc Sabatella

Marc: “First, I am confused…” yes, I didn’t know that.

“OK, but as noted, we write it with the sharp sign in front of the note” sure, but even when writing notes by hand, I always draw the note first. The other way is just not natural.

It’s been proven that reading (even prose) is not strictly left-to-right; people recognise clusters and even Boustrophedon is used during reading (which is why line lengths are relatively short normally, especially in newspaper and novel printing), so it stands to be a natural conclusion that note recognition isn’t it either.

“To me the tie-breaker in favor of the new system is not having to hear the wrong pitch first”… sure, but hearing both means I’m aware whether it’s a courtesy or needed accidental. I actually prefer hearing the wrong pitch first.

I guess https://xkcd.com/1172/ applies…

@BGS, you select the accidental then enter the note or use the palette after the note is entered. The palette works while in note entry mode.

What about a shortcut for toggling courtesy accidentals: something like pressing equal. The rest can be done with the arrows.
My personal workflow for courtesy accidentals is:
- exit note entry (esc)
- click the natural sign
- press N
- press right arrow to go to next note.

This does take some time compared to finale's one key press. (especially the clicking part)

This shortcut should not be only available in note entry though.

I personally would like and use a single-key "courtesy accidental" command that figured out the necessary accidental based on the actual pitch of the note. But I suspect that those who are largely copying existing music would prefer separate commands.

Marr... a courtesy shortcut would be nice, but again, to say that "the arrows do the rest" is false since there are, albeit rare, double sharps and flats to be utilized on occasion.

Just add them both, the old set of five bindable commands to add accidentals after the fact, and the new courtesy accidental magic command, and don’t bind any of them and let the user decide whether they want the new default, the old commands, or the to-be-created magic command in their shortcuts.

(FWIW, I have = bound to ♮ (and # to ♯ and - to ♭) in my 3.2 and am seriously wondering whether I should upgrade to 3.3 before the old behaviour is, well not back but at least customisably recoverable.)

I’d not use a command to auto-apply a courtesy accidental because when inputting I’m not tracking which are courtesy and which aren’t. (I’d appreciate a function to automatically add parenthesēs to all extant courtesy accidentals (and at the same time removing them if an accidental is not courtesy) in batch, though. A plugin for courtesy accidentals exists but is only concerned with adding them, which specifically goes against my needs as well.)

My 2 cents:

I'm one of those who largely copies scores. In my experience, it's better to not try to figure out if the accidental is courtesy or required I just apply it the same way, with my shortcut. A shortcut that would apply a courtesy accidental (probably not = since it does something else) could be useful. If you press it and nothing happens or you get the wrong accidental you know you need to fix it, but the current accidental before the note method would make this a workflow interruption.

Toggle autoplace. But I think it may be missing in macOS because I didn't realize we maintained a separate list so I didn't add it until , well, the PR just got merged a couple of days ago.

Bump! Is this feature being considered for v4.0?

More than a year on from the introduction of the new way of applying accidentals I am still finding it difficult to adapt my workflow.

I'm currently working on Ravel's transcription of Debussy's 'Nuages' nocturne, with its beautiful and highly chromatic chords, and for the first time using MuseScore feels like a chore.

FWIW, I don't see it linked here, but I did produce an experimental PR to address this some time ago - see https://github.com/musescore/MuseScore/pull/5505. This implements a command "apply input state", which actually goes further - it also applies a selected duration retroactively. I didn't really push for it because I figured it might be a bit controversial, but I do think both behaviors would be quite welcome by most.

So the way it works is, immediately after entering a note, if you select either a duration or an accidental then want it to apply retroactively, just issue the new command. It does mean one additional keystroke over the old method, but it's the same keystroke for all accidentals / durations which is nice. Also, this proposed new command ends up being useful for implementing a style of note input where you first select pitch then duration. Still, I can see the appeal of individual commands for the accidentals at least that apply them immediately.

Anyhow, this feels like something for the design "team" to decide on. My code should still be good but just needs a rebase.

The additional keystroke needed would also completely kill this for me.

This is about keeping the input method that existed prior to 3.3 possible as a nōn-default alternative.

I really appreciate your efforts Marc, but I agree with mirabilos, the need for two keystrokes wouldn't improve on current workflow. An accidental can be applied retroactively with two keystrokes currently, via either "Esc" + the keyboard shortcut for the accidental, or up/down arrow + "j" to change enharmonic spelling (not always necessary of course, but often needed when replicating scores exactly).

The single-keystroke, retroactive accidental application is the feature I'd like to see restored. This would complement the many terrific workflow improvements implemented in versions 3.3+, which is why rolling back to v3.2 now is not an option (thanks anyway for the suggestion mirabilos).

When I first began this suggestion thread, I imagined that it would have been re-implemented fairly soon afterwards for some reason. The age-old rhetorical question: Has it really been a whole year?

Understood, but I would observe, my proposed command is still more efficient than the current workaround of leaving note input mode, because when you leave note input mode, you then also need to re-enter it, and also reposition the note input cursor. So it's actually two additional keystrokes above and beyond, and on top of that just really feels more disruptive.

Anyhow, if someone wants to implement a set of explicit commands that apply retroactively, I certainly wouldn't stand in their way.

Status active PR created

Well, since I like BSG so much, what the hell:
Here's a PR that provides versions of the accidental shortcuts as "(non-toggle)" as it was back in 3.2.3 and before. It could be updated so that when there's an accidental already present it would be removed so that there would be a "pseudo" toggle-ability with "post-application", but that's not involved here for now.


"(non-toggle)" is probably not the best thing to call the commands, but this should get it going.

In reply to by [DELETED] 1831606

I’ve always assigned - (think “minus”) to flat, = (think “level”) to natural (which conflicts with the newer toggle-autoplace, but since I don’t use the latter, I’m keeping this) and + (think “plus”) to sharp. On a US-layout keyboard, these are all next to each other, so this also helps mnemonically, and in 2.x times they were all otherwise unused.

I don’t use shortcuts for double sharp/flat (yet), just the toolbar icons… they are rare enough… but I probably should. I’m open for suggestions that match this scheme of mine.

Bonus keybindings: ( (think “parenthesis”) to parenthesise an accidental or note, and ) (think “exclude”) to separate from beaming (needed in some vocal music where you have a lot of freestanding 8ths).

In reply to by worldwideweary

Thank you so much for this fix.

My keyboard shortcuts have always been...
; for a natural
' for a flat
"#" for a sharp
@ for a double flat
~ for a double sharp

All accessible from three adjacent keys (on a UK keyboard layout). So with the left hand typing notes and the right hand applying accidentals to those notes, workflow for note entry was (and now will be again) very quick indeed.


Glad to read this will help your workflow. And to be sure, the dev-team already merged the English PR. As of now, if you download a nightly build, these will show up under "(non-toggle)" with everything else worded the same.

Fix version