Request for stacked chord extentions

• Nov 9, 2020 - 14:45
Reported version
3.5
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

Over the years a request for stacked chord extension pops up:
- Stacked Jazz Chord Extensions
- Chord formatting
- Stacking chord extensions
- Stacking with code
- How to stack chord alterations to make a smaller chord symbol
- Chord Appearance (Jazz)
- Stacking chord extensions

Instead of having the extension horizontally:
unstacked.png
the request is having the extensions stacked (vertically):
stacked.png

In the topics some examples are given for some chord extensions but they require a dedicated XML file describing the chords.
This request is asking for an "out-of-the-box" solution.


Comments

Possible options are:

1) Dedicated chord definitions file (e.g. chords_jazz_stacked
With this solution, the user has the specify which file to use. Besides this is not that user friendly, it also has a big disadvantage: It requires all possible combinations must be specified.

2) A style option specifying whether stacked or non stacked chord extensions must be used.
With such a style option, it is not possible to have both stacked and non-stacked chords in the same score. More important, the chord parser becomes more complicated since, when parsing a chord description like C7(b9b5) is must decide which parts must be stacked (b5 and b9).

3) An extension of the "chord syntax".
Instead of having a style option, the chord description itself will define which parts has to be stacked, e.g. C7(.b5.b9). Here the . (dot) specifies the element has be stacked. An alternative could be C7(.b5..b9). Here the number of dots will specify the "stacking level", one dot is highest line, 2 dots is next line, and so on.
The advantage of this option is it gives the user the maximal control.

4) ....

While extending the chord symbol syntax might be more flexible, it's not very discoverable. I'd prefer to see it happen automatically, and controllable by a style option. I've given some, but not a ton, of thought to this, and am pretty sure it's doable within the current rendering engine without too much effort. Note the parser is mostly separate, it probably wouldn't be affected. Doing it by hard-coding the XML file is to me not worth the effort. It's probably almost as much work to do well as writing the code, it sends us down the rabbit hole of pre-ordaining which symbols we can handle, it's font-specific, etc.

Instead, for example, we could add a new checkbox to the chord symbol style to turn stacking on or off. As for where wxyz gets stacked as wx over yz or wy over xz, to me it doesn't matter much. I think people would figure it out and adjust, chords with more than two extensions are pretty rare anyhow. I would be fine with picking whoever ends up being easier to implement, frankly.

I would envision an implementation of this requiring some but not a lot of cooperation from the XML file, kind of like how I implement style-based superscripting.

In reply to by Marc Sabatella

I agree, modifying the XML is the least desirable solution. For the 2 other options, I can't tell which one is preferred over the other. Although, I agree, extending the chord syntax is not very discoverable (and looks a little clumsy too).
Altogether, it might be better to start investigating the second option, using a style option. Let's what I can do.

I have just lived with run-on extensions thinking you guys are way too busy to fool with a request like this, but if you guys are already thinking of making code changes to accomodate stacked extensions, I'm all in!
Thanks to Marc for his self described hack to make this happen by using a custom chord xml file. In the mean time I will be using this. I deal with a lot of extensions and folks are not used to reading them horizontal and it wastes horizontal real estate on my scores. Thanks, Bones.