Chord symbol with (sus) in parenthesis not formatted well in Jazz style

• Mar 8, 2018 - 04:16

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.


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 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 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 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.

Do you still have an unanswered question? Please log in first to post your question.