[MU4 Issue] Change enharmonic spelling commands not implemented

[wizofaus]

Describe the bug The "change enharmonic spelling" command has not been ported into MU4. Also "respell pitches" to reverse this is applying to the whole score rather than just the selected notes - this is as per MU3, but is inconsistent with other commands and expected behaviour.

Expected behavior The "change enharmonic spelling" commands mapped to shortcut key "J" and "ctrl+J" for (changing just concert pitch view or transposing pitch view, depending what's been viewed currently) should work as per MU3.

Respell pitches should revert these for just the selected notes, rather than affecting other notes (unless no notes are selected, then it can safely apply to the whole score)

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information): Windows 10

Additional context Add any other context about the problem here.

[wizofaus]

@Tantacrul or @bkunda - current MU3 behaviour is that "change enharmonic spelling" commands only apply to selected notes, whereas "respell pitches" (which is very poorly documented BTW) always applies to the whole score. Is there any good reason for that discrepancy? I can understand that it's unlikely you'd ever want "change enharmonic spelling" to apply to the whole score so it would make sense to require select-all first if you really did, whereas for "respell pitches" it's more reasonably likely you might want it to apply to the whole score, but I would think for consistency's sake if you want a command to apply all notes you should ensure they're selected first (after all it's a simple combination key stroke to do so!). At any rate, surely "respell pitches" should only apply to selected notes if there are any...

[Tantacrul]

I'd agree. My feeling is that these options should be combined (assuming they actually produce the same results. I don't know if they are written separately and if so, which one is more effective). I think the behaviour should be:

1. If nothing is selected, the function applies to the whole score (possibly with a confirmation dialog, with a 'don't show me this again' checkbox)
2. If the user makes a selection, the function only applies to that selection

I always think it's better to avoid a situation where a feature doesn't do anything - throwing a dialog like 'select X for this feature to work'.

We should also keep the options wherever they are currently found but just use a single name.

[Jojo-Schmitz]

"Change enharmonic spelling" and "Respell pitches" are not doing the same thing. The latter does it once (no matter how often you call it) and as per the current key signature, the former on every incocation 'cycles' through the various enharmonic spellings, doesn't care for the current key signature.

[bkunda]

There is a further complication as well: "change enharmonic spelling" appears to run in two different "modes" - one that alters the spelling in both concert pitch and transposed modes (for transposing instruments), the other which alters the spelling only in current (concert) mode.

There is some scattered documentation on this in the forum (which I suspect you are probably already aware of): https://musescore.org/en/node/110646 https://musescore.org/en/node/206176

This looks to me like a situation where there is potentially quite a lot of powerful functionality available, but it is difficult to find and takes a while to figure out how it works (I'm still figuring it out 😅).

I agree with @Tantacrul that somehow combining these affordances is something we should look into. At the very least, the ways in which "respell notes", "change enharmonic spelling in current mode" and "change enharmonic spelling in both modes" all function need to be made clearer to users.

[wizofaus]

I'd agree. My feeling is that these options should be combined (assuming they actually produce the same results. I don't know if they are written separately and if so, which one is more effective). I think the behaviour should be:

1. If nothing is selected, the function applies to the whole score (possibly with a confirmation dialog, with a 'don't show me this again' checkbox)
2. If the user makes a selection, the function only applies to that selection

I always think it's better to avoid a situation where a feature doesn't do anything - throwing a dialog like 'select X for this feature to work'.

We should also keep the options wherever they are currently found but just use a single name.

It's pretty standard practice in other similar applications where you can have functions that sensibly apply to selected objects that if there are no selected objects they're simply disabled.

As it is currently many of the commands in the Tools menu do nothing if nothing's selected, and it's very unlikely you'd ever want any of them to work on the full score. Actually they're quite inconsistent: Transpose - automatically shows the whole score as selected if nothing's already selected, but does nothing until you confirm the transposition you want in the dialog. Explode/Implode/Realise chord symbols - do nothing at all if nothing's selected Voice exchange/Split measure - give an error (no staff selected) if nothing is selected Remove selected change/Fill slashes/Toggle rhythmic slash - do nothing at all if nothing's selected Respell pitches - respell all pitches in entire score according to key signature regardless of what's selected Regroup rhythms/Resequence Rehearsal Marks - if nothing selected, applies to whole score (but unlike Transpose, does not visibly change selection), otherwise, if range selected, applies to that, otherwise (individual items selected), does nothing Unroll repeats - creates a new score, and always applies to whole score no matter what's selected. NB: cannot be UNDONE! I don't know how this will work in MU4 which can't have multiple scores open currently... Copy lyrics to clipboard - always copies lyrics of whole score to clipboard, regardless of what's selected. Note that you can't then paste them back into another score. Image capture - strange command, doesn't relate to what's selected at all (and is actually a "mode" not a command - it's not immediately obvious how to actually do the capture) Remove empty trailing bars - always applies to whole score, regardless of what's selected.

My real issue though is having a mixture of some commands that DO apply to the whole score if nothing is selected and ones that don't - as it is you can be left wondering whether a command actually did anything. In fact ideally every command, no matter what, should always give at least some visual feedback that it completed, even if it's just to put a quick "No notes needed respelling" message in the status bar.

Personally I wouldn't have ANY commands that automatically applied to the whole score, you should always have to "select all" first. "Remove empty trailing bars" is the only one I might make an exception for.

BTW that's just commands in the tools menu - there's a bunch more commands in the Edit menu or other toolbars or that aren't in menus at all but can be assigned to shortcut keys (like Change Enharmonic Spelling) that all have their own weird and wonderful variations.

[Tantacrul]

Sounds like we need to do a bit more work than previously thought, since the functions are different. However, I don't agree that we should disable features because something isn't selected (or throw an error). We should always assume the user had an intent and we should try to satisfy it.

• For example, if you did choose 'respell pitches' with nothing selected on the score, you could trigger 'select all' as part of the command, so the user will see a visual change (the whole score will remain selected after the respelling has been applied). Bear in mind, they can always 'undo' if they don't like the result.
• Disabling features until something is selected is hard to learn. Better to throw an error. Better again to try and achieve a positive result if we can. If the user doesn't get the desired result the first time, they'll at least then learn how the feature works.
• I don't think we should aim for iron consistency between all options, given that some are never intended to work on the whole score. In some cases, an error dialog will have to be shown, etc.
• It does feel like we will need to spend some time going through each of these (and comparing to the other notation apps) and figure out what general rules we should apply and where it's OK to not have consistent behaviour. I think this might be a job for @bkunda !

[bkunda]

Yes I think there's no immediate quick fix for this one. Happy to look into it. A very well-spotted UX problem, @wizofaus!

[Tantacrul]

Yes I think there's no immediate quick fix for this one. Happy to look into it. A very well-spotted UX problem, @wizofaus!

Yes. Thanks so much. Extremely useful!

[wizofaus]

There is a further complication as well: "change enharmonic spelling" appears to run in two different "modes" - one that alters the spelling in both concert pitch and transposed modes (for transposing instruments), the other which alters the spelling only in current (concert) mode.

There is some scattered documentation on this in the forum (which I suspect you are probably already aware of): https://musescore.org/en/node/110646 https://musescore.org/en/node/206176

This looks to me like a situation where there is potentially quite a lot of powerful functionality available, but it is difficult to find and takes a while to figure out how it works (I'm still figuring it out 😅).

I agree with @Tantacrul that somehow combining these affordances is something we should look into. At the very least, the ways in which "respell notes", "change enharmonic spelling in current mode" and "change enharmonic spelling in both modes" all function need to be made clearer to users.

Not only that but "change enharmonic spelling" can cycle through 3 different possible spellings - except for the notes like Ab/Gb/Db that only have two possible spellings (NB it also includes Bb & Eb, it won't let you spell those as C or F double flat for some reason), which can cause some odd results when you select multiple notes some of which have 2 spellings and some 3.

Also personally I find it frustrating that there's no command to "respell with flats" and "respell with sharps" - the only way to do it is to use the down/up arrow for sharps or up/down arrow for flats (which works surprisingly well but isn't very obvious).

TBH I haven't quite worked out what "Respell" does exactly yet - it seems to attempt to minimize the number of accidentals needed, but once it's decided that one F# should become a Gb, it seems to affect ALL F#s in the score even if that makes no sense.

[bkunda]

I ran a test and got 6 possible spelling combinations (including what I had originally entered). Crazy!

[wizofaus]

If I put C# A# F# into a score with no key signature, respell pitches does nothing. But if I then add an E# in another measure, respell changes those first 3 but leaves the E# as is. That makes no sense...

[wizofaus]

Actually I just realised Ab is the only note that can literally only have 2 possible enharmonic spellings - Gb can be E double sharp, and Db can be B double sharp.

[wizofaus]

(BTW I don't think any of the above takes away from the value of the PR I put up, I haven't really added any further inconsistency - "respell pitches" just acts like "Regroup rhythms/Resequence Rehearsal Marks" now, with the added bonus that it works on list (individual note) selections too - because it sensibly can, whereas those other commands can't really).

[MarcSabatella]

For the record, respell pitches is context dependent, looking at surrounding pitches to try to decide on the optimum spelling according to an algorithm published in a research paper once upon a time. It’s not a particularly valuable command as is, but there have been previous discussions (forum etc) about alternative algorithms that might work better, including a reference somewhere to one that allegedly protrudes the “correct” results in something like 95% of all cases tested in the works of Mozart, or something like that.

[Jojo-Schmitz]

My expactation would be for it to reduce the number of accidental as much as possible, to match the key signature.

But that might well be an over-simplification.

[MarcSabatella]

I don't think that is necessarily the goal - it could actually had as much to do with analyzing the music to determine an appropriate key for it. Not that the code itself adds one.

For some more context, see:

https://musescore.org/en/node/296828 https://musescore.org/en/node/293080

(I assume "[DELETED] 1831606" is in fact BSG)

The second thread has links to actual research papers and proposed new code.

[wizofaus]

For the record, respell pitches is context dependent, looking at surrounding pitches to try to decide on the optimum spelling according to an algorithm published in a research paper once upon a time. It’s not a particularly valuable command as is, but there have been previous discussions (forum etc) about alternative algorithms that might work better, including a reference somewhere to one that allegedly protrudes the “correct” results in something like 95% of all cases tested in the works of Mozart, or something like that.

Seems strange that a not-particularly-useful command would figure so prominently in the Tools menu yet the "change enharmonic spelling" commands which are definitely very useful are hidden away as shortcut-bound actions only (at least, I could find how to add it to a toolbar).

It certainly seems like a command that's ripe for a rewrite, and fortunately a) this needn't have any UI/UX implementations (having options to control it might make sense, but I think just improving the current interaction-free behaviour is enough b) it's unlikely any users are going to be upset if it starts performing differently to the current algorithm c) there are already a number of algorithms out there that could do the job. So it's really just a matter of deciding on which algorithm and prioritising it. It's not a command I could see myself using often so I'm not in a hurry to put my hand up at this stage. Either way, it needs to be better documented.

[wizofaus]

BTW while this issue got closed @Tantacrul, there's still a large number of unresolved issues discussed above, particularly regarding inconsistency of commands in the Tools menu depending on whether anything's selected etc. here

[Tantacrul]

We’ll need a new issue, which is basically to create a design for refining these options / making spelling changes more discoverable, etc.

I’m on vacation today, so not really able to dedicate much time to looking through the comment history to create a new issue.