How to represent chord 13sus4 ?

[infojunkie]

Are the following equivalent? Which is preferred?

      <harmony>
        <kind text="13sus">dominant-13th</kind>
        <degree>
          <degree-value>3</degree-value>
          <degree-alter>0</degree-alter>
          <degree-type>subtract</degree-type>
        </degree>
        <degree>
          <degree-value>4</degree-value>
          <degree-alter>0</degree-alter>
          <degree-type>add</degree-type>
        </degree>
      </harmony>

and

      <harmony>
        <kind text="13sus">suspended</kind>
        <degree>
          <degree-value>7</degree-value>
          <degree-alter>-1</degree-alter>
          <degree-type>add</degree-type>
        </degree>
        <degree>
          <degree-value>9</degree-value>
          <degree-alter>0</degree-alter>
          <degree-type>add</degree-type>
        </degree>
        <degree>
          <degree-value>13</degree-value>
          <degree-alter>0</degree-alter>
          <degree-type>add</degree-type>
        </degree>
      </harmony>

[mdgood]

That's a great question @infojunkie. Currently they are pretty much equivalent, depending on whether you want to emphasize the 13th or suspended elements of the chord. Usually I go with the dominant-13th, reflecting what comes first in the chord symbol.

I've thought of adding more <kind> values to support this, but with the combination of 7th / 9th / 11th / 13th with suspended seconds and fourths, that could be a lot of values to add. What do people think?

Edit: This is assuming that you meant suspended-fourth instead of suspended in that second example. The former is a valid value for the <kind> element but the latter is not.

[infojunkie]

According to the excellent https://github.com/no-chris/chord-symbol, "sus" is not a chord quality. Would be great for @no-chris to chime in here. I think that suspended could be represented orthogonally to the chord quality: regardless of major/minor/dominant, a chord can be suspended (4 or 2) or not. For example:

<kind suspended="4">dominant-13th</kind>

[jsawruk]

@mdgood: I don't like the idea of adding more <kind> values, as it could be a very long list.

I like @infojunkie's proposal, but I think it should be flexible enough to support 6/9 chords and "add2". Perhaps:

<kind suffix="sus4">dominant-13th</kind>

Alternatively, maybe add suspended to degree-type-value, giving the following for 13sus4 (the omitted 3rd could be implied or explicitly encoded):

<harmony>
  <kind text="13sus">dominant-13th</kind>
  <degree>
    <degree-value>4</degree-value>
    <degree-alter>0</degree-alter>
    <degree-type>suspended</degree-type>
  </degree>
</harmony>

[no-chris]

(I cleaned up my GitHub notifications, I should be better in the future at spotting those mentions 😅 )

<harmony>
  <kind text="13sus">dominant-13th</kind>
  <degree>
    <degree-value>4</degree-value>
    <degree-alter>0</degree-alter>
    <degree-type>suspended</degree-type>
  </degree>
</harmony>

I think that solution makes more sense than the suffix/suspended attribute (why would we have a dedicated attribute for this specific interval change?). I would expect this to automatically omit the 3, which could be explicitly added back if needed (Csus4(add 3) is a valid chord in the Real book, for ex).

If I understand well that would behave a bit like the <degree-type>alter</degree-type> in the sense that it impacts another degree of the chord.

[infojunkie]

This is a really interesting conversation that Michael has aptly labeled "semantics", because we're knee deep in them :heart_eyes:

I think that solution makes more sense than the suffix/suspended attribute (why would we have a dedicated attribute for this specific interval change?)

Here's my position:

• kind is only concerned with the chord quality, not the additional altered degrees. Therefore, it would not make sense to write kind text="13sus" unless the chord quality itself is declared as dominant13-suspended. There seems to be a consensus of avoiding the combination explosion of existing chord qualities x suspended.

• My proposal to add suspended as an attribute to kind comes from the fact that today's MusicXML lists it as a separate quality - which it cannot be, because it combines with other qualities. Moving it to an attribute of the quality allows it to be orthogonal to the "main" quality, but still remain in the realm of qualities.

• The suspended degree-type would be different from alter because the latter alters its own degree, whereas suspended would imply that another degree (i.e. the 3rd) needs to be omitted. This sounds like an extra burden to impose on the client app.

[no-chris]

but I think it should be flexible enough to support 6/9 chords and "add2".

Could somebody elaborate a bit why something specific would be needed for 6/9 support?

I would have expected this to work?

<harmony>
  <kind text="6/9">major-sixth</kind>
  <degree>
    <degree-value>9</degree-value>
    <degree-alter>0</degree-alter>
    <degree-type>add</degree-type>
  </degree>
</harmony>

I'm not sure to understand which problem suffix="6/9" would actually solve?

My proposal to add suspended as an attribute to kind comes from the fact that today's MusicXML lists it as a separate quality - which it cannot be, because it combines with other qualities.

I indeed had spotted that when I though about how to convert chord-symbol internal chord representation to musicXml.

Moving it to an attribute of the quality allows it to be orthogonal to the "main" quality, but still remain in the realm of qualities.

I still find this a bit weird. Most - if not all - attributes of the kind element deal with rendering, not intervals. Having a new degree-type would avoid mixing concerns and keep all degrees changes in the same place.

This sounds like an extra burden to impose on the client app.

Either solutions will require client apps to adapt and I'm not sure that one is better than the other in this regard.

[infojunkie]

I should also add here that my original motivation for opening this issue is that many apps that parse MusicXML are confused by the representation of sus chords. Only some apps understand that "omit3, add4" means "sus" - others just display those altered degrees verbatim, thereby canceling the intent of the composer. Fixing this ambiguity at the format level is better than opening bug reports on each app!

[mdgood]

If the issue is appearance during import, then you will want to change the MusicXML in your original example to use <degree print-object="no"> for each of the degree elements. Sorry I missed this - I thought you were asking about the semantic part of the chord representation.

At this point I don't think we will want to change anything for this in the MusicXML 4.0 schema. MusicXML already lets you represent these chords. It's a matter of application support for the features, both writing and reading. Adding another way to represent these chords may well make the problem worse instead of better.

[infojunkie]

My question was indeed about semantics, and the argument is that sus is not a quality on its own. The semantic ambiguity that exists today is the root cause of appearance issues. I mentioned the appearance issue as a symptom of the underlying ambiguity.

[mdgood]

In the music notation context, I think there is a difference between sus2 and sus4 chords and chords like 13sus. From the notation, there's no way to know whether sus2 and sus4 are alterations of major or minor triads. Hence they need their own distinct <kind> values. For 13sus, on the other hand, the notation does indicate a major quality that gets altered.

This leads me to think that the first example would be preferred, so now I may have a more theory-grounded understanding of my initial preference. However I still am unclear on the how any semantic ambiguity affects interchange, as opposed to incomplete implementations of formatting features.

[mdgood]

To get back to @no-chris's suggestion for <degree-type>suspended</degree-type>: @infojunkie is correct that this would be different than the alter value, because it would affect two different degrees with a single element.

While both approaches capture more semantics than MusicXML 3.1's representation, they are adding another way of doing things that can already be represented accurately. In my experience this tends to make interchange worse rather than better, because of the implementation burden issues mentioned above.

I think this discussion might better help us refine how MNX represents chords, rather than leading to changes within MusicXML.

[infojunkie]

I see - this is starting to make sense to me :bulb: Thanks for taking the time to respond on this lengthy thread!

If I understand you correctly, you're saying that the "bare" sus4 or sus2 chords would use the suspended-X kind, whereas any other extended chord that also happens to be suspended would use the relevant extension's kind, and annotate the suspended degree using a degree alteration.

If that's the case, then it would be great to explicitly document this distinction, to encourage the apps to export and import the "right thing".

And finally, is the intent of the kind text attribute to document only the chord kind, or the chord as a whole (including altered degrees)?

[mdgood]

Thank you for this discussion! I had not thought about this distinction before - well, at least not for many, many years. I tend to agree that this would be a good thing to document, to encourage a single way to represent these chords.

For your last question. I think we can clarify that the text attribute for the <kind> can include alterations such as "sus" that represent multiple degree elements. Does that answer your question or is there something I am missing?

[infojunkie]

I think we can clarify that the text attribute for the can include alterations such as "sus" that represent multiple degree elements. Does that answer your question or is there something I am missing?

Sounds great! Thank you.