Chord symbol with (sus) in parenthesis not formatted well in Jazz style
On 2.1 and latest 2.2 (e37f251) I notice that parenthesis around a (sus) in the chord symbol spelling isn't formatted nicely:
It is fine for default non-jazz style:
For those that disagree with the use of parenthesis around the sus, I defend their usage as a way to communicate to player that the sus is optional.
Comments
Not sure what the way to deal with this would be. "sus" should normally not be superscripted, but everything that is more normally parenthesized is superscripted. So somehow we'd either need to superscript sus when parenthesized, or refrain from superscripting parens when applied to sus. Not sure there is a direct way to do that. It's possible we can get the former result by adding render instructions for "sus" separately as modifier versus extension, but I suspect it's always modifier.
Might instead need to hardcode the specific chords in the XML file as is done for 6/9. Feel free to try that out. You'd need to handle 7(sus), 9(sus), and 13(sus) individually. And same if you want versions with b9 etc. A bit of a can of worms.
In reply to Not sure what the way to… by Marc Sabatella
yeah I guess the (sus) should all be subscripted in which case it is not the parenthesis that are "incorrectly formatted" but rather the "sus" part.
I don't think having all these special cases is the ideal way to go, cause there could be any number of other cases. I wonder if (sus) with the parenthesis could be added as a parsing unit instead.
In reply to yeah I guess the (sus)… by ericfontainejazz
In theory. But the current implementation doesn't have a good way to do such context-aware parsing. To use compiler-speak, it's kind of more of a "lexer" than a "parser". We could conceivably graft on some special-casing after the fact in the parser rather than the XML file. Like, after we build the token list, go back and look for "(" "sus" ")" and if found, tweak the "sus" in a way that will allow us to match a different token or render rule.
Ultimately, though, I'd eventually hope to see a more flexible rendering system developed for 3.0, where the user can customize rendering easily himself.
In reply to In theory. But the current… by Marc Sabatella
Ok, well I'm not going to bother to try to fix this for 2.2, but whoever rehauls chord symbols for 3.0 hopefully can be aware about this.
The other types of cases that would need to be handled are (sus4) and (sus2). Would be nice if there was a "parsing" stage which grouped all tokens in between parentheses, as a general solution.