'On the fly' enharmonic respelling is broken?

I’m running version 5.1.30. Something seems to have changed in the way enharmonic auto-respelling is handled, which is messing majorly with years of muscle memory. I can’t however find anything about this in the Version History, so what’s going on here? Let me provide an example. (Apologies for the verbosity.)

Suppose I have just entered this note on my MIDI keyboard. Treble clef, no key signature.

Scherm­afbeelding 2024-04-13 om 19.12.43

I know it should be Ab, so at this exact point (without exiting Input mode) I respell it with Alt=. My muscle memory tells me that this “fixates” the spelling of that note, so even when I then play an A natural on the keyboard, it will stay put. But now it still reverts to G# so I then have to exit input mode, select the G# and respell it again.

Similarly, if I know the note does have to be G# but followed by G natural, I used to be able to pre-empt the respelling by hitting Alt= followed by Alt- — again, to fix it as being a G#. This, too, is now broken in the same way.

Now I’m not sure that this was changed in version 5.1.30 specifically, but it’s the first time I’m inputting anything slightly chromatic since the most recent update, and almost immediately this change was messing with my workflow. My question is: has this been changed on purpose? If so, why? And is there a checkbox somewhere to revert to the way it worked previously?

PS: There is something in the 5.1.30 version history about enharmonic respelling in extended tonalty systems. This however is bog-standard 12EDO.

1 Like

Yes, I think the change broke the old behaviour, which may not have been deliberate to start with.

But I agree that some way to pre-empt the change is needed. Otherwise there’s not point in having “smart” enharmonics on at all. :cry:

1 Like

Would turning off “Allow spelling of notes to be adjusted retrospectively” in Note Input Options work for you?

90% of the time, it’s a useful feature; but 10% of the time, the user can foresee “the wrong adjustment” is about to occur: and there’s no easy way of pre-empting that, short of leaving Note Entry, and going back to change the note.

Turning it off as a solution means doing without its benefit for 90% of the time.

1 Like

I’m aware that that’s the balance for you, Ben, but I wondered whether that was also the experience for the original poster. When we first implemented all the MIDI spelling rules we were surprised at how different people’s expectations were.


I don’t envy you the job of trying to please everyone, certainly!


It depends quite a bit on what I’m inputting. For capital-C Classical music or older, the algorithm gets it right about 95% of the time. Some composers however turn out to be particularly resistant against the auto-respelling. Stravinsky is the first one to come to mind; at his worst the success rate may be closer to 60/40. In general there’s a clear inverse correlation between the success rate and the number of aug/dim chords in the source material. Nevertheless it is still a majority so no, disallowing retroactive spelling would not in fact save me time.

1 Like

To provide a brief follow-up here: we’ve been looking into this issue and we believe we will be able to fix it in the next update, all being well.


Today’s 5.1.32 update fixes this issue.