FWIW, spaces are allowed *within* a chord symbol extension - eg, "Bb6 4" is OK and the space is preserved. Spaces *between* the main elements of the chord symbol are lost. By "main elements", I mean,
Root Extension Slash Bass
Actually, due to what I would consider a bug, currently if you have a space between the slash and the bass note, the space is not lost, but then the bass note is not properly recognized either and won't transpose nor will "b" and "#" turn into flat and sharp.
I have a simple fix that would allow a space between the root and extension to be kept (and fix the bug I mentioned), but making it so other spaces would be opreserved would require deeper changes to the parsing. I'm thinking that's probably good enough?
Come to think of it, this would be less of an issue if note names weren't required. Then things like IVm^7 would be parsed properly. My first example isn't common and even if I could find an instance of it, it would still be specialist notation, but chord symbols without the letters A-G are useful. That would of course open another can of transposition worms.
I agree it could be worth considering an empty root as still valid for the purpose of parsing the rest. This would be a more significant change though. Worth submitting a spearate feature request for that. For now, I've submitted a PR that at least allows a space between the root and extension, and fixes the bug where a space before a bass note prevents the bass note from being parsed properly.
Comments
FWIW, spaces are allowed *within* a chord symbol extension - eg, "Bb6 4" is OK and the space is preserved. Spaces *between* the main elements of the chord symbol are lost. By "main elements", I mean,
Root Extension Slash Bass
Actually, due to what I would consider a bug, currently if you have a space between the slash and the bass note, the space is not lost, but then the bass note is not properly recognized either and won't transpose nor will "b" and "#" turn into flat and sharp.
I have a simple fix that would allow a space between the root and extension to be kept (and fix the bug I mentioned), but making it so other spaces would be opreserved would require deeper changes to the parsing. I'm thinking that's probably good enough?
Whoops, instead of making the text bold, that was meant to be:
A chord such as B D# F# G for example
Come to think of it, this would be less of an issue if note names weren't required. Then things like IVm^7 would be parsed properly. My first example isn't common and even if I could find an instance of it, it would still be specialist notation, but chord symbols without the letters A-G are useful. That would of course open another can of transposition worms.
I agree it could be worth considering an empty root as still valid for the purpose of parsing the rest. This would be a more significant change though. Worth submitting a spearate feature request for that. For now, I've submitted a PR that at least allows a space between the root and extension, and fixes the bug where a space before a bass note prevents the bass note from being parsed properly.
https://github.com/musescore/MuseScore/pull/2219
Fixed in branch master, commit 5dfdca9f1c
fix #76531: handling of spaces within chord symbols
Fixed in branch master, commit fc1535d7bd
Merge pull request #2219 from MarcSabatella/76531-chord-symbol-space
fix #76531: handling of spaces within chord symbols
Fixed in branch 2.0.3, commit 54dcbaa82f
fix #76531: handling of spaces within chord symbols
Automatically closed -- issue fixed for 2 weeks with no activity.