MusicXml export of chord symbols in Release Candidate
I am starting to use the Release Candidate in my work flow for creating MusicXml files.
I have two questions:
1. What has happened to the chord property dialog ?
I use this for validating that the chord has been recognised to ensure that the export will go correctly.
2. Is there an error with the export of this chord : F#9sus4
<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>
Comments
The chord property dialog is gone.
My method to tell whether a chord got detected is to enter it in lowercase, if if flips to upper case, it got detected, works well unless you allow lowercase chord symbols...
In reply to The chord property dialog is by Jojo-Schmitz
Thanks Jojo,
Would be more helpful if we had a more definite indication as even totally wrongly entered data, such as s# will be indicated as a chord when right clicking on it.
What I need to know now is if the chord symbol export example I gave is correct, and if so, how to interpret it when I read it into my app so as to recreate the originally entered symbol.
Can you help here ?
In reply to Thanks Jojo, Would be more by Simon Giddings
Basically, there is no more all or nothing to chord recognition. We recognize what we can, ignore the rest.
In reply to Basically, there is no more by Marc Sabatella
Good evening Marc,
Yes, I understood this part of Jojo's reply.
However, as my objective is correctly exported chord symbols with MusicXml, I need to know if MuseScore has been able to understand it. There is no information given to this effect.
When an incorrect chord has been entered (ie MuseScore does not parse it), nothing allows us to understand this. Right clicking on the chord name will produce a contextual menu with the heading "Symbole d'accord" (I am working in French).
Could something be done to give correct user feedback ?
In reply to Good evening Marc, Yes, I by Simon Giddings
Is the MusicXML export not sufficient in itself? I guess I need to understand more about the context here - who is "the user", is he freely typing chords off the top of his head and expecting to get something in particular from the MusicXML, at what point would he need to know that somethng he entered wasn't understood etc. Examples of specific chord symbols you have encountered that a real user has entered expecting to be recognized but weren't would also be helpful in my understanding what you are looking for. Because right now, my default answer is, "anything a user would reaosnably expect to have export as MusicXML will be".
As it is, the export of F#9sus4 looks correct to me - or, I should say, one of several possible correct interpretations.
In reply to Is the MusicXML export not by Marc Sabatella
Good morning Mark,
Thanks for your reply.
I requested help from the MusicXml forum and got a reply from Michael Good.
He raised an issue in that there is a part missing from the export.
You can see his full reply here : "Correctly interpretting chord harmony nodes"
In short, the kind node's text attribute is incomplete :
<kind text="9sus4">suspended-fourth</kind>
Can this be fixed, do you think ?
In reply to Good morning Mark, Thanks for by Simon Giddings
OK, so the semantic information is correct, just the "text" isn't.
I'm fuzzy on the defailts of how the text field is supposed to work in the case of complex chord symbols. My understanding is that each tag can have it's own text, so you never write the entire text - just piece by piece. So the "kind" tag has some of the text, but the various "degree" tags could potentially have their own. That's my understanding, anyhow. Maybe it's not right. But my understanding has been, since the "kind" tag is not itself describing the ninth, it's incorrect to include the 9 in the text. If that's not right, then probably text is not right lots of places. I could use clarificiation on that: is the "kind" text supported to just include the entire text for the whole chord symbol?
Anyhow, dominant 7 & higher with sus4 is kind of a special case for us, because you really could be exporting as "sus4" with extensions in degree tags (as we do), or as "9" with sus4 as a degree tag (which I also have code to code, ifdef'ed out.
In reply to OK, so the semantic by Marc Sabatella
I've got an account for musicxml forum, I'll followup to the original thread there.
In reply to I've got an account for by Marc Sabatella
Hi Marc,
Following your exchange with Michael Good, can you tell me if this will be included in the final release ?
In reply to Hi Marc, Following your by Simon Giddings
I'm still awaiting a reply from my followup, so no, the way it is now is the way it will be for 2.0. When I get clarification on how this is all actually supposed to work, I can make changes that will be available in future nightly builds and the next release after 2.0. Meanwhile, programs reading MuseScore MusicXML output will have to do what I had previously understood to be what they are suppsoed to do in the first place - construct their own text representation from the semantic description. MuseScore is capable of doing this, and from what I understand at least some other programs can too. So even if it's technically not complete, it should still be sufficient for at least some purpsoes. Still not understanding your specific use case. I gather you are writing your own program to parse MusicXML; I'd personally recommend you not rely on text attributes completely.
In reply to I'm still awaiting a reply by Marc Sabatella
Hi Marc,
Posting this here as it is still the same subject - even though on the official release.
So, I tested a number of chord symbols - exporting to MusicXml and then re-importing to "see what happens".
Two things I noticed :
1. Not sure how I am supposed to specify, for example the chord of C with a flattened 7th as Cb7 will give a Cb with a 7th.
2. If I specify Cdim13, the re-imported display is Cdim7add9add11add13 = a problem ?
Should I file a problem here ?
In reply to Hi Marc, Posting this here as by Simon Giddings
ad 1. I think it got to be C7b
In reply to Hi Marc, Posting this here as by Simon Giddings
Regarding 1, I'm not sure what chord you mean. Flattened seventh compared to what? C7 already means a flatted seventh compared to Cma7: C E G Bb instead of C E G B. Do you mean a chord with a *double* flatted seventh - C E G Bbb? I've never such a chord notated, ever. And in any case, C7b looks like a typo, not a chord symbol :-) I suspect you are referring to simply C7, but am not sure.
Cdim13 is ambiguous. We don't normally specify upper extensions on diminished chords because given that seventh is already doubvle flatted, it's not at all clear what kinf of 9, 11, or 13 this chord should take. So I'd say, it's a nonsense chord you should not worry about.
I have to confess I'm still a buit confused by the original discussion and how text attributes are intended to be used - seems the recommendations are still unclear. But I *think* i am hearing it is OK to write a full "text" attribute for the "kind" tag in all cases and always set an explicit null "text" attribute for the degree tags, so I'll look into that.
In reply to Regarding 1, I'm not sure by Marc Sabatella
And once again my complete lack of knowledge with harmonies shows ;-)
In reply to And once again my complete by Jojo-Schmitz
I'm at a similar stage also, Jojo ;-)
To replay to what you said, Marc ....
Ok, my example was not the best, but I will not press the matter.
For the second issue, I was simply wanting to point out that the new release accepted Cdim13 when creating the score.
I then export this out as MusicXml.
But, when I open the same MusicXml file in the new release, it does not give back Cdim13, as you have seen.
The issue is with the new release.
In reply to I'm at a similar stage also, by Simon Giddings
EDITED after re-reading Michael Good's most recent response in the MusicXML
Yes, indeed, borderline nonsense chords like Cdim13 will output "correct" borderline nonsense MusicXML, and that MusicXML can be imported to produce another "correct" borderline nonsense chord, but realistically, it won't always be the *same* spelling of the borderline nonsense chord after going through MusicXML export & import. It will be equivalent, but not necessarily the same spelling. Such is the nature of trying to reconstruct syntax from semantics - it won't always be 1-1.
In contrast, 1.3 if given a nonsense chord (and Cdim13 would be considered nonsense), will export *nothing*. And given "correct" but nonsensical MusicXML exported by 2.0 or another program, 1.3 will display either nothing or something that is probably even more nonsensical.
1.3 can only handle a very specific set of chords - the chords it was preprogrammed to recognize. If you don't type an *exact* character-for-character match, then the chord is simply unrecognized and no MusicXML is output at all. For instance, if C7b5b9 is on the recognized list but you type C7b9b5, or C7(b5b9), then the chord is simply not recognized in 1.3, because you didn't spell it *exactly* the way it was expecting. It was this reliance on forcing you to spell things one way and one way only that enabled the MusicXML output to be more deterministic. It basically didn't work at all if the chord was not recognized, but if a chord was on the short list of recognized chord ids, then it just output the pre-programmed MusicXML for that particular chord id. And as you are noticing, this always had a full text attribute, which according to my best understanding is not technically the best way of doing it as we should be only using text "as necessary" like we try to now.
In 2.0, we recognzie virtually everything and try to figure out how to export it, and this gets quite complicated because there is not always a 1-1 correspondence between the syntactic elements of the chord and the MusicXML elements that need to be output to represent it - the "9" in the F#9sus chord being a perfect case in point.
Anyhow, again, if it is truly acceptable for me to always put a full and complete text attribute on the kind tag and a null one on the degree tags, then that should do what is needed here and be technically correct, although to my mind, kind of lying a little bit. So I am still leaning toward trying to do the right thing and just use that hack in the cases where I can tell we won't be getting the right answer otherwise.
Meanwhile, as I mentioned in email, if you wish to limit yourself to a specific set of chord symbols and hardcode MusicXML complete with text attributes, you can use one of the 1.3 chord description files, or roll one of your own to your liking - this is easier with 2.0 even though we don't really advertise that.
In reply to EDITED after re-reading by Marc Sabatella
Hi Marc,
Just to add a bit of "oil to the fire" ...
I needed to declare the chord A4/9 but was not able to in v1.3
So I tried to do it in v2.0.
When I exported it to MusicXML, here is what came out -
<harmony print-frame="no">
<root>
<root-step>A</root-step>
</root>
<kind>major</kind>
<degree>
<degree-value>4</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>
I have been told that this chord is "spelled" as 1-4-5-7b-9.
So, I would have expected to see this -
<harmony print-frame="no">
<root>
<root-step>A</root-step>
</root>
<kind>major</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>
<degree>
<degree-value>5</degree-value>
<degree-alter>0</degree-alter>
<degree-type>add</degree-type>
</degree>
<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>
</harmony>
What do you think ?
In reply to Hi Marc, Just to add a bit of by Simon Giddings
A4/9 is not a common/standard chord symbol, so I don't think there is any one particular correct interpretation. But I agree with what we output, not what you were told to expect :-). That is, I don't see any reason why a musician seeing that chord symbol should expect a seventh of any kind. The chord you descrbe ia A9sus4 - the very chord that started this discussion. The first number in a chord symbol tells how high to stack thirds and is the only number that can "imply" other numebrs. So a 9 that occurs anywhere but in the first position after the root mnever implies a seventh. Thus, neither Aadd9 nor A6/9 include sevenths. Neither should A4/9.
I've taken a look at how we are calculating the kind text, and aside from the very special case of chords with a "kind" of "suspended-fourth" but that are also dominant 7, 9, 11, or 13 chords, we are doing the right thing as far as I can tell. That is, the kind text shows only what is necessary to reproduce the kind itself, and normally this is the right thing to do. Information about additional degrees is expected to be re-constructed by the importing program, as Michael explicitly says should happen. it's only where there is ambiguity that a program should need to export more than this.
Which is to say, 1.3 was generally doing things wrong, and relying on full text descriptions to appear in the "kind" tag is not a good idea, as I think you were acknowledging in a response to the thread n the MusicXML forum?
Regarding 9sus4 specifically, the ambiguity comes from the fact that there is debate over whetehr the kind should be considered suspended-fourth or dominant-ninth. I wish suspended-fourth had not been included in the list of kinds, and that it was always treated as just a modification to another chord type. But given that it does exist, and programs do seem to use it, I guess we need to sort out that ambiguity, so I'll be looking into it. it's very much a sepcial case, though - in general, as far as I can tell, what we do is good, and unfortunately that means you will need your code to understand chord symbols a bit more than it apparently does currently.
In reply to A4/9 is not a common/standard by Marc Sabatella
So, from what you are saying, the exported chord symbol is not its spelling, but rather what should be displayed.
In this case A4/9 is exactly what is exported.
It is up to the importing application, where necessary, to do the correct interpretation.
Have I, at last, understood correctly ?
I know that I am insisting a bit with this, but since I have to adapt my MusicXML importing code, I want to do it correctly. Notably to be in accordance with v2.0 of MuseScore.
In reply to So, from what you are saying, by Simon Giddings
I am not understanding this sentence: "the exported chord symbol is not its spelling, but rather what should be displayed". Which exported chord symbol, and what do you mean but "its spelling" and how does this different from "what should be displayed"? Are you talking about A4/9 specifically here?
As I said, it's not a common chord symbol at all - I wouldn't be surprised if it had never been written once in the entire history of music until you tried it :-). What we export is unambiguously that chord - I mean, anyhow who understood MusicXML and read what we exported would *play* it correctly. But there is not enough information in what we export to unambiguously *display* it. Which is to say, three different musicians who were showed that chord on the piano and asked to come up with a chord symbol for it might come up with three different spellings, and it's quite likely that none of them would actually come up with A4/9. Similarly, three different computer programs who saw what we exported and tried to come up with a spelling of the chord might come up with three different spellings, and it's quite likely that none of them would actually come up with A4/9 either.
To me, this is normal and not a problem - not when it comes to human beings and not when it comes to computer programs. Until the world settles on a single unambiguous syntax for chord symbos, I expect such differences will always exist. For 2.0, I was much more interested in exporting correct information about the *structure" of each chord than exporting complete information about the specific one of many ways any given human musician might choose to *spell* each chord. In the easy cases, most human musicians and most computer programs will agree on the spelling for a given chord and there is no cause for concern.
But I am coming to realize that at least in some particular cases, there might be reason to care more which specific spelling was actually in use in the score at the moment it was exported (keep in mind that MuseScore can change spellings at the push of a button). So it occurs to me I could have two different modes - the more basic one we use now, where only minimal spelling information is included, and a more complete one where we basically do as 1.3 did and stuff the entire chord symbol into the kind tag "text" attribute - hoping the importing program can figure out how to parse and render that.
The need to parse the string is actually the Achilles heel of that approach. A program that reconstructs a chord symbol from a *semantic* description can presumably be trusted to do intellgitent things with information like "add 9 alter -1" - know to display this as "b9" with an actual flat sign and not the letter "b", superscript if appropriate for the font being used, etc. But if all I do is stuff the string "7b9" into the "text" attribute, I suspect a lot of programs won't deal with that very well at all. Or, for that matter, what if the string as typed into MuseScore inclue parantheses and commas, but the importing program doesn't support those, or not in the same way we do. And so on. Unless the importing program has essentially the same parser we do, it's likely to do a *worse* job with the text we give it than it would reconstructing the chord symbol from the semantic description. And that's ne reason why I was so focuses on getting the semantics right.
Anyhow, I am happy to help in any way I can here, whether it consists of explaining things about chord symbols in general, explaining things about how MuseScore works, or making required changes in MuseScore to be more compliant with the standard.
In reply to I am not understanding this by Marc Sabatella
Hi Marc,
You wrote - I am not understanding this sentence: "the exported chord symbol is not its spelling, but rather what should be displayed".
What I meant here is that, still using this chord A4/9 as the example, the spelling of the chord is not exported, ie there is no indication that the 3rd has been removed or that a flat 7th has been added. I presume therefor that the importing application (in my case my automated processing tool), will need to understand the implied parts.
A4/9 = 1 - 4 - 5 - flat 7 - 9
Exported A4/9 = A root with 4th added and 9th added
From this, I presume that the presence of an added 4th implies the removal of the 3rd and the presence of an added 9th implies the addition of a flat 7th.
So, what is exported is the display ie: A plus 4th plus 9th = A4/9.
Have I understood correctly ?
In reply to Hi Marc, You wrote - I am not by Simon Giddings
What I am saying is, it is not correct to assume that A4/9 would not have a third or that it would have a seventh. There is a perfectly good chord symbol for that already: A9sus4. A4/9, while as I said not a common chord symbol at all, does not in itself tell a human musician anything about omitting the third or adding a seventh. So I think that chord should literally be played 1 3 5 4 9. If someone had meant the 4 to replace the 3, they should have written "sus4", not just "4". And if they mean to include a seventh, they should have put the 9 first, because only the first number present in a chord symbol ever implies the presence of other notes 9 implies 7, 11 implies 7 and 9, 13 implies 7, 9, and 11. A 9, 11, or 13 placed anything but immediately after the root does *not* imply a seventh or any other chord tones.
So, what is exported is correct according a literal reading of that chord symbol - the chord is 1 3 5 4 9, and that is exactly what is exported.
In reply to What I am saying is, it is by Marc Sabatella
Thanks Marc,
I am getting the picture now :-)
I tried to export a chord in parenthesis - obviously did not work (or I would not be mentioning it).
The chord and parenthesis are recognised because when I enter (g) I get back ( G ).
Before bothering you with this, I asked if MusicXML is capable of coding this.
Here is Michael Good's reply - Parenthesis around chord symbols
With the adjustments you are being kind enough to envisage, could this be included ?
In reply to Thanks Marc, I am getting the by Simon Giddings
When you say it didn't work, you mean, the parentheses themselves didn't export, but the chord symbol itself did, right?
I am starting to look at the code changes that might be required now. Again, the goal of the parser was to always export correct semantic information, but it is true we won't capture every single bit of syntactic detail that was present in the original. The same is true of other elements of MusicXML import and export for that matter - we really don't make any attempt to deal with many details of formatting. But I am beginning to see that for chord symbols, it might be best to adopt some sort of compromise approach. Still not totally sure what will make sense.
In reply to When you say it didn't work, by Marc Sabatella
Yes, you are quite right, the chord symbol itself did export correctly.
I thought that since MuseScore has already detected and accepted the parentheses, the information would be available and therefor not too difficult to export. Especially if it is a single, optional, node directly under the harmony node.
In reply to Yes, you are quite right, the by Simon Giddings
It's not difficult if we are assumng parentheses always completely enclose a single chord symbol. It's not clear how to handle ( A7b9 Dmi7 G7 ) or other sequences. So I asked in MusicXML forum.
Anyhow, my response was more about the general changes we are discussion, not this case specifically. I'm currently testing a hack for the kind & degree texts for 9sus4 chords to propose the output proposed by Michael. I think it's still going to be the case, though, that you may need to reset your expectations a bit. You *will* have to reconstruct chord symbols from the semantics, and there will continue to be cases where an importing program not come up with character-for-chsaracter the same thing that was originally typed. Chords symbols are complex beasts.
In reply to It's not difficult if we are by Marc Sabatella
Hi Marc,
Is there an issue record I can follow to know when it will be available in a nightly build ?
This is a blocking issue for me to be migrating my personal code from v1.3 to v2.0.
In reply to Hi Marc, Is there an issue by Simon Giddings
It's #53936: Incomplete MusicXML text attributes for 7sus4 chords, fixed a few days ago.
I'm not sure what you mean about this being a "blocking" issue, though. Don't you still need to fix the basic issue here - the fact that you currently are relying completely on text attributes rather than building the spelling from the degree tags themselves? I have no plans to go back to the 1.3 scheme of always putting the full name into the "kind" text. I only added a special-case hack to put the 9 into the "kind" text for for 9sus4 (also 7sus4, 11sus4, and 13sus4). Frankly, I still think applications should be able to figure out the correct spelling of that chord even without that hack - a good applications should realize that a kind of suspended-fourth with degrees of add b7 and add 9 is properly and commonly spelled 9sus4. But since Michael suggested we use this hack, I added it. Those are the only chords where this is an issue, though, as far as I know.
In reply to It's #53936: Incomplete by Marc Sabatella
Totally agree with you Marc.
What I meant is that I needed to wait until you had come to a definitive conclusion of how MuseScore v2.0 would export chord symbols, so as to then start the updating of my own code.
I am fully aware that my code needs changing and will be able to start doing this.
I presume that this change is only available within nightly builds, is that right ?
In reply to Totally agree with you by Simon Giddings
Correct. There is a "master" that will eventually become 2.1, and a "branch" that will become 2.0.1 sooner rather than later, and this change is merged into both. So it will be in 2.0.1 when that comes out in the very near future, also in 2.1 when that comes out somewhat later. As of now, this os the only chord symbol export change planned or likely for 2.0.1. It we get further feedback there is always the chance we'll make other changes for 2.1. Checking to see how Finale or Sibelius import the MusicXML we export is always a good way to check to see if what we export is reasonable, so do report issues you find. But overall, I would not be expecting to see substantive problems, just a few isolated corner cases like this one where we need to export more info. Your example of a diminished thirteenth chord would be another such example if only there were any agreed upon standard for that would even mean.
In reply to Correct. There is a "master" by Marc Sabatella
Thanks for that clear explanation.
Just to let you know, Michael Good has posted an answer to your question regarding parenthesis around groups of chords here
In reply to Thanks for that clear by Simon Giddings
See [#114771]. Apparently I did something incorrectly - maybe the text attributew was supposed to be on the degree-value, not on the degree itself? If anyone has clarification or other comments, please followup in that issue thread.
In reply to See [#114771]. Apparently I by Marc Sabatella
rather https://musescore.org/en/node/114771 (wouldn't it be nice it the [#NNNNN] would work for forum articles too?)
In reply to See [#114771]. Apparently I by Marc Sabatella
See also #186706: [XML export] export 7sus(4) chord to MusicXML fails reimport: "Element degree contains unknown attribute text."
In reply to Hi Marc, Posting this here as by Simon Giddings
b7 isn't used, because of 7 is already flatted itself.
there is two possibilities for seventh chords: 7 (dominant) and Maj7
"dim7" is special chord = Edim7: e, g, bb, (db)<-- (not:
Edimb7)"diminished Maj 7" : Cm(Maj7)b5