Clarify what degree-type=alter is supposed to represent

[no-chris]

Hello,

Should a degree with a degree-type of alter should be used to represent:

• an altered degree in a chord. For example the #9 of a dominant 7th chord, eg C7(#9). This is what seems to be the widely accepted definition of an altered chord. The ninth is not part of the dominant 7th chord per see but still, it is considered an altered degree of the chord.
• an altered degree in the chord kind, meaning that in C7(#9), the #9 would need to be encoded as an add and not an alter, because the dominant-seventh kind is defined as a major triad, minor seventh and thus, do not contain a ninth.

For me The degree-type type indicates if this degree is an addition, alteration, or subtraction relative to the kind of the current chord. is ambiguous, because '#9' is an alteration of a dominant chord but could be an add in the context of another chord kind (for example in the context of an augmented chord: you will find A+(add b9,add #9) in the realbook)

Maybe the documentation could clarify this particular point? 🙏🏻

[mdgood]

I am not sure what can be clarified here. The meaning of each <kind> values is spelled out in the schema. A C7(#9) is clearly notated in MusicXML terms as a <kind>dominant</kind> with an added sharpened 9th (degree-value of 9, degree-alter of 1, degree-type of add).

If your application focuses more on harmonic analysis than notation, you may indeed want to represent it as a <kind>dominant-ninth</kind> with an altered ninth. However this is true for many chords and harmonies. There are lots of ways to spell and analyze them, and what works best often depends on the specific context. For a notation application, it's usually best to stick to the notated interpretation.

I suspect I am missing something in your request. If you have a suggested clarification for the documentation please let us know!

[no-chris]

Thanks for your answer.

We are indeed talking about notation and not harmonic analysis. The issue I see is that this notation system is also partially used to print the chord symbol name. I'm saying partially because kind/@text is the other part, so if my understanding is correct:

• we have a kind that defines 1/ the base intervals of the chords and 2/ how the first part of the chord is supposed to be rendered via kind/@text (everything before the parentheses, basically)
• then we have the degree(s), that 1/ allow to refine the base intervals and 2/ are use to generate the "parentheses" part of the chord symbol, enforced by the degree/@print-object

The issue I see is that how this second part is build might slightly differ from how the degrees affect the kind.

For example, if C7(#9) is supposed to be encoded dominant + 9, 1, add then how C(add9) is supposed to be encoded? I would assume major + 9, 0, add. But in that case, how I am supposed to know that the first is supposed to be rendered (#9) and the second (add 9) without performing harmonic analysis on the kind?

Another example: C7(b5,b9) would be encoded dominant + 5, -1, alter, 9, -1, add. I would expect most software to print out: C7(b5, add b9), unless they perform some harmonic analysis to recognise that in the context of a dominant, a b9 is an alteration and not an add, and then print out C7(b5,b9) as intended.

Last example, because you could argue that the previous chords could be encoded as dominant-ninth and with an altered 9th: C7(b13) cannot be encoded dominant-13th + 13, -1, alter because this chord symbol does not imply a 9th nor an 11th, whereas dominant-13th does. So dominant + 13, -1, add could be rendered C7(add b13)

add, alter and subtract make perfect sense in the context of describing degrees, but in the context of rendering they dangerously map to add, alteration and omit. I'm probably not alone in this confusion.

IMHO it would be better to have a separate system to store the full chord-symbol string as intended to be printed out rather than having a mixed system. degree, as it is, is perfect for encoding a chord, not so much for rendering it as I see it.

I see multiple ways the documentation could be improved:

• make it explicit that add / alter / subtract should not used for deciding with which prefix a degree should be printed out (add, omit, no prefix), but that the rendering software should implement its own logic to decide.
• make it explicit if the parentheses content can be encoded in the kind/@text? for ex7(b13), with all degree with print-object="no" in complex cases?

[mdgood]

I think using the text attributes of the <degree-value> and <degree-type> elements in addition to the features you mention will allow you to specify all of these cases unambiguously. Is there a case where you think this is not so?

[no-chris]

mmmm right, so C7(b9):

<harmony>
    <kind text="7">dominant</kind>
    <degree>
        <degree-value text="b9">9</degree-value>
        <degree-alter>-1</degree-alter>
        <degree-type>add</degree-type>
   </degree>
</harmony>

Would be the way?

What is the expected behavior if the text attribute of <degree-type> is not provided? Display the value (in that case, add) or do not display anything? If the former then we would need to explicitly encode <degree-type text="">.

[no-chris]

Hello,

Thanks for the very useful pointers 🙌🏻 Could you please clarify the following points if possible?

Intended value for text attributes

• degree-value@text: should receive the degree with the alteration: ‘b9’, ‘#11’ ?
• degree-value@symbol: the only case I found would be the chord Cdim7(add Ma7), in that case degree-text should be 7 and symbol should be major? Are there any other usages for symbol in the context of degree-value?
• degree-type@text: should receive the desired prefix for the degree: add, omit, or even nothing?

Are these the intended usage of the text attributes?

Degree without a prefix

In the case of C7(b9), is it correct to set the text attribute to an empty string? b9 is encoded as an add but usually considered as an alteration of the chord. I would prefer alt not to be displayed, as stated by most rules of chord symbol writing, but I don't want the degree-type (add) to be displayed either

Write add only once

In the case of A+(add b9,#9), I want only the first add to be displayed. In that case, is it correct to set the text attribute to add for b9, and to an empty string for #9?

This also raises the question of in which order should the degrees are displayed. Is it safe to assume that the order in which they are declared is the order in which they should be displayed?

Double alteration

C7(b5,#5) should have two degree with a degree-value of 5, a degree-type of alter, and should differ only by degree-alter (-1 for the first one, 1 for the second one). Is this correct?

Thanks a lot!

[mdgood]

Hi @no-chris - Sorry I missed your question from last week, but let me try to address all of these now.

• degree-value@text - This should be "" for things like b9 and #11: <degree-value text="">9</degree-value>. The ` element is enough for an application to display the accidental symbols.
• degree-value@symbol: The triangle for major would be the most common, but I am pretty sure I have seen chord symbols that use any of these symbols to alter a degree.
• degree-type@text: Exactly, use "omit", "add", or whatever prefix is being used, and specify "" if there is no prefix.
• add b9,#9: Almost - I would use text="add" for the first and text="," for the second.
• C7(b5,#5): I would say this needs one <degree-type>alter</degree-type> and one <degree-type>add</degree-type>. That way it is clear you have 5 degrees in the chord; otherwise it could be interpreted as 4. It doesn't matter which is which as long at the text attributes are set accordingly.

Is it safe to assume that the order in which they are declared is the order in which they should be displayed? That's a good question. We haven't explicitly stated that in the MusicXML documentation, and perhaps we should. We could also specify that for the stack-degrees attribute, where I suspect the preferred ordering would be top to bottom.

I hope this helps! Please let me know if there are any other questions.

[no-chris]

That helps a lot, thanks 🙏

I think I do have a few more questions indeed:

• degree-value@text - This should be "" for things like b9 and #11: <degree-value text="">9</degree-value>. The element is enough for an application to display the accidental symbols.
  • now this really confuses me. Could you give an example of what the text attribute would be used for?
  • also, text="" seem to behave differently between degree-value and degree-type. In the second case, it means "do not display anything", but here it would mean "display the degree based on the degree-value and degree-alter content" ? Why do we need text="" at all in that case? Does it act as some kind of prefix (but I thought we had a separate symbol attribute for this prefix)? 🤔 🤯
• On a general note, it would be helpful to specify what should be the expected result if those text attributes are not filled. If we look at the documentation, it seems that the expected behavior is not to to display anything in case degree-type is add or alter but to display omit in case it is equal to subtract, is this correct?
• And for degree-value, the default behavior with no text attribute seems to be displaying the degree with the accidental.
• regarding stack-degrees=yes I'm assuming that in that case, i would not need to encode the comas , in degree-type@text. I think I'm slowly starting to get the philosophy behind musicXml, and especially all those rendering-related attributes that confused me at first. I was expecting an encoding syntax that would just abstract the "model" of a musical piece, but it's actually more than just that: it is (or at least it can be) "this musical piece, written in this very specific way"

If you think that can be helpful, and once I fully understand all the subtleties of it, I'm happy to provide various samples of chords encoded in musicXml to enrich the documentation.

[mdgood]

@no-chris Once again I apologize for the delay in answering these questions. I think additional examples of chord encodings for the documentation would be a great idea. To answer the MusicXML representation questions:

• degree-value@text is used for symbols that are spelled like "add 3rd" or "omit 5th". In this case the "3rd" and "5th" would be what is included in the text attribute for degree-value.
• I don't know why I included the text="" in that degree-value example. That's wrong, you would just omit the attribute. Sorry for causing your confusion there!
• The defaults if the text attributes are omitted are application-dependent. Often the defaults within an application can change depending on a style that the user has chosen.
• Your understanding of stack-degrees and MusicXML's model seems correct. MusicXML generally tries to put the semantics into elements, then add appearance and playback information in attributes (or very specific elements like <print> and <sound>). The focus was initially on semantics but customers soon wanted much finer control of appearance. That became a big focus of development starting in MusicXML 1.1 and continuing today.

I hope this helps and that I didn't get anything else wrong again to cause more confusion! If things are still unclear please let us know.

[mdgood]

I think we have addressed the original question and most of the follow-ons, either here and/or in the MusicXML 4.0 documentation. Sometimes these were covered in other issues.

I will be closing this issue now. @no-chris, if there is something that still needs to be clarified, or you have examples that we could add to the documentation in the future, could you please start a new issue for that? Thanks again for your help with clarifying things here.