MakeMusic
SmartMusic Finale Garritan MusicXML

Correctly interpretting chord harmony nodes

Moderator: Michael Good

Correctly interpretting chord harmony nodes

Postby zimrahdev » Wed Mar 18, 2015 1:31 pm

Good evening (at least it is here),

I am starting to work with musicxml exports from the release candidate of MuseScore and need to validate chord exports.

This is what I get when I export the chord F#9sus4
Code: Select all
<harmony print-frame="no">
   <root>
      <root-step>F</root-step>
      <root-alter>1</root-alter>
   </root>
   <kind text="sus4">suspended-fourth</kind>
   <degree>
      <degree-value>7</degree-value>
      <degree-alter>0</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>
</harmony>


Two questions follow :
1. Is this a correct export
2. How should I process this to re-create the originally entered chord.

Can anyone help here ?
zimrahdev
 
Posts: 19
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby Michael Good » Wed Mar 18, 2015 6:20 pm

No, that export is not completely correct - or at least it is incomplete. You won't be able to recreate the original formatting from that export. To do that, the export would need to look like this:

Code: Select all
<harmony print-frame="no">
   <root>
      <root-step>F</root-step>
      <root-alter>1</root-alter>
   </root>
   <kind text="9sus4">suspended-fourth</kind>
   <degree>
      <degree-value text="">7</degree-value>
      <degree-alter>0</degree-alter>
      <degree-type text="">add</degree-type>
   </degree>
   <degree>
      <degree-value text="">9</degree-value>
      <degree-alter>0</degree-alter>
      <degree-type text="">add</degree-type>
   </degree>
</harmony>


This of course is assuming that when you say F#9sus4, you mean F# 9sus4 and not F #9sus4. The latter would have a root-alter value of 0 and a final degree-alter value of 1.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby zimrahdev » Thu Mar 19, 2015 3:10 am

Good morning Michael,

Great, thank you for this.
I will forward the info to the MuseScore team.

Simon
zimrahdev
 
Posts: 19
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby Marc Sabatella » Thu Mar 19, 2015 8:25 am

Simon forwarded this to me. I updated the MusicXML export for MuseScore a couple of years ago, and *kind of* remember the code :-)

I may or may not have a misconception about the "text" attribute. My impression was, the "text" attribute for a "kind: tag was supposed to only capture the part of the chord symbol expressed by the kind tag itself, and that information about the addition degree alterations / additions / subtractions was not supposed to be included in the "text" for the main "kind" tag. So similarly for, say, C7b9, I thought the "text" attribute for the kind tag would only talk about the "7" and not about the "b9". Am I wrong? Should the text attribute for "kind" just spit out the whole chord symbol exactly as it appears in the score? Is there something special about sus4 chords that makes them unique here?

BTW, I already special case chords like 9sus4 because really, left to my own devices, I'd be more inclined to think of 9sus4 as a dominant ninth that just happens to have a fourth replacing a third, as opposed to a sus4 that just happens to have a seventh and ninth added. And my chord symbol parser is much happier to construct the chord the way I had in mind. But I take some pains to export it the way I thought was preferred, and to handle that on import as well.
Marc Sabatella
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby Michael Good » Thu Mar 19, 2015 11:03 am

Hi Marc,

MusicXML handles either encoding - a dominant-ninth kind with an added fourth and removed third, or a suspended-fourth kind with added sevenths and ninths.

The text attributes are used so that applications can recreate exactly how things are spelled. There is no restriction on which text gets associated with which element, in part because of situations like this one. With the current encoding in Simon's original post, an application could only do something like sus4 add 7 add 9, which you don't want. So the "9sus4" needs to be in the kind text, with the two degree texts set to none. Most applications have degree text following the kind text, and with this encoding of the chord semantics that won't work without the degree text explicitly set to empty strings.

With the alternative encoding of a dominant-ninth kind with added fourth and removed third, you could use a text of "9" for the kind element, a text of "sus4" for the added fourth, and a text of "" for the removed third. So it's not a matter of putting the entire chord symbol in the kind text, but finding what encoding best reflects both the semantics and appearance.

Either way is fine. The goal is to encode the music so that both the semantics and the appearance can be re-created from an application reading the MusicXML file. The original example only encodes the semantics, not the appearance.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby Marc Sabatella » Fri Mar 20, 2015 5:21 pm

That helps, but I'm still not totally clear. Since it is sometimes difficult to sort out which piece of text contributed to which specific tag, is it acceptable to spit the whole text out as the text in the "kind" tag?

I had been thinking that I was supposed to output text only when it was something other than the default. I was assuming applications were supposed to understand the standard / default way of representing the various things it sees, and reconstruct the chord symbol correctly using default values from that. So I'd have expected any application to turn what we export into F#9sus4. In any case, it's what MuseScore does on import :-)

So, to use another example that's hopefully less ambiguous, what about C7b9? I would have assumed we needed no text attributrs at all - that any program should be able to figure out how to render that from a good semantic description. But if I do need to include text attributes, does it make sense to put "7b9" in the kind text and hope that programs don't see that but also see the degree tag and decide they need to add *another* "b9" to that, yielding "C7b9b9"? In other words, is it *wrong* to actually interpret the semantics of the degree tags and construct text them? Is the text of a chord supposed to be *entirely* determined by text tags? If so, my assumption would be, then the only acceptable answers are "7b9" in the kind and nothing in the degree, or "7" in the kind and "b9" in the degree.
Marc Sabatella
 
Posts: 24
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby Michael Good » Mon Mar 23, 2015 10:20 am

No, the text of a chord is not supposed to be entirely determined by text tags. I believe most applications do try to construct chord symbols from the semantics based on a 1-to-1 match of semantic element to text, unless the text attribute provides an override. So 7b9 works fine without any text attributes because the text matches the semantics 1-to-1. With 9sus4 there is no 1-1 matching of text to semantics as represented by the children of the harmony element. So in this case you need text tags to guide the reading application, as suggested in my previous reply.

If you put the entire chord symbol text in the kind element, you must also set the text attribute on the degree elements to an empty string. Otherwise you will likely get degrees being appended to your kind symbol, and that will be the fault of the export, not the import.
Michael Good
VP of MusicXML Technologies
MakeMusic, Inc.
User avatar
Michael Good
 
Posts: 2197
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby zimrahdev » Tue Mar 24, 2015 2:34 am

Thank you Michael for these clarifications.

Taking into account your comments about 1 to 1 semantic matching, I realise that I need to be able to correctly parse these degree nodes to obtain, where possible, the intended chord spelling.
In my parser up to now I have been relying on the text attribute of the kind node - which worked great !

However, I want to be more serious and accurate in my parser - but my knowledge of chord construction is too limited.

Are you able to point me to any resource (on line if possible) which will enable me to better understand chord construction and how it should be represented and interpreted in MusicXml ?
zimrahdev
 
Posts: 19
Joined: March, 2014
Reputation: 0

Re: Correctly interpretting chord harmony nodes

Postby Marc Sabatella » Fri Mar 27, 2015 11:25 am

FWIW, this is an area where I feel more examples in the documentation would be quite helpful!

What I am hearing from this discussion is that in general, it's fine for text tags on kind elements to only contain information on the kind itself (eg, for Cma9#11
Code: Select all
<kind text="ma9">major-ninth</kind>
for "ma9", with the #11 implied by the degree tag that will follow. So in general, what MuseScore is doing for 2.0 is fine. The only issue comes up in the special cases where there is some sort of ambiguity, like 9sus4.

To me, it seemed pretty clear that seeing an "add 7" and an "add 9" on a suspended-fourth should mean I turn this to "9sus4" on import, so I don't think it *unreasonable* to hope a program can do this. But I can now see that some programs might indeed try to turn that into Csus4add7add9 and that the only way to explicitly prevent this is to add appropriate text attributes - both adding the "9" to the kind tag, *and* explicitly setting the degree texts to null.

I will be looking into special-casing this in our MusicXML export, but it might help to understand when else this is likely to come up. As far as I can tell, what we are doing for other chords should be OK. For example, for "Cma9", we output a kind of major-ninth with a text of "ma9", and the degree tag for the contains no text but rather expects that any program should know "add degree 11 alter 1" means you display simply "#11", not "add". Hopefully that is OK?
Marc Sabatella
 
Posts: 24
Joined: March, 2014
Reputation: 0

Who is online

Users browsing this forum: No registered users and 1 guest

cron