N.C. over bass note chord symbol doesn't auto-format flats and sharps

For the record, I think the better workaround is to use staff text - and you can give it the Chord Symbol text style for consistency. Another would be to add the bass note on the same beat, then the manual offset is less "fragile" and less likely to need updating if the measure width changes.

Meanwhile, yes, in principle this seems doable. Merely parsing the chord appropriate is the easy part, but it would probably be more work to find all the places where we assume a chord with an unparseable root would not have a valid bass note. Things like transposition especially. Not impossible, but not as trivial as the parsing.

Hi! Awesome feature request! It seems that MuseScore auto-formats # and b to ♯ and ♭ when the first character of the chord symbol is a letter A–G—at least when the content after the slash is just one note (see attached).

What if the code were changed such that chord symbols auto-format # and b to ♯ and ♭ REGARDLESS of the starting letter? Is there a downside to that? If so, how about just including "N," so that it auto-formats when the starting letters are A–G or N (for N.C.)? That way we wouldn't have to use a workaround at all.

This is especially important with the new feature to align chords horizontally. I'd hate for an N.C./G chord symbol to be at the wrong height because I used a Staff Text workaround.

Also, with the new chord playback, I imagine that having a "chord" that's actually Staff Text wouldn't work properly.

The downside is that there is other text you might want to include in a chord symbol - N.C. is only one of many possible pieces of text you might want to have. And some of the other things you might want may include the letter "b" or the ordinary hash symbol "#". So it's important we only do the conversion in chord symbols we can actually parse and understand. Right now, we'd be capable of skipping everything before the slash and parsing what comes after, but the problem would be as I said above - we'd have to make sure to update the places in the code that assume valid bass notes imply valid roots as well.

Good point about staff text not aligning, so it would be good to solve this someday. But FWIW, "N.C." won't playback anyhow.

Besides "N.C.," what sorts of text might someone use in a chord symbol, as opposed to staff text? I've only been using MuseScore since March, and I haven't gotten very creative with my chord symbol usage yet. :)

Somewhat related, I've written some slash chord examples to illustrate how MuseScore treats them. Notice that the actual slash marks for the chord symbols in m20, 24, and 27–30 are a little higher and smaller than the rest of them. It seems to happen only when both the "numerator" and "denominator" of the slash chord are invalid (not a real note/chord), but the "numerator" starts with a letter between A and G. I've also included a B♭ part to show which chord symbols transpose. Finally, I attached the .mscz file so you can tab through the chords to see exactly what was typed into them. Sorry if you knew all this already . . . again, I'm new here. :)

It seems that the true solution would be to add the possibility to introduce the symbol b or # yourself instead of relying on MuseScore guessing.
Because, Marc, you say : there are chord texts non parsable where the letter b must stay b.
Well yes, but then there are also non parsable chord texts where the letter b needs to become the symbol b!
So the only universal solution is to allow the user to introduce the symbols himself!
That doesn't mean that I want to remove the current parsing and symbol "guessing", entering A + [letter b] would continue to recognize letter b as symbol b

Actually you can add the flat or sharp sign yourself - Ctrl+Shift+B and Ctrl+Shift+# work while entering chord symbols. But we turn them back into 'b' and '#' when we process the chord symbol. It simplifies the parsing and hopefully helps the user who might not have realize he can simply type 'b' or '#', and was implemented by user request. We could consider revert that improvement to help this case, but actually, it really wouldn't help, because in order for this to really work (transpose, export to MusicXML, potentially playback) we need it to parse normally.

I wouldn't say it wouldn't help.
It would allow to get the wanted visual result much more easily than using staff text with manual vertical alignments.
But indeed true parsing will enable automatic transposition.
Anyway I would say that the process of turning back b symbol as b letter makes only sense when MuseScore is able to parse it back to b symbol. Otherwise it is destroying user input.