Problem with chord names on opening .xml files
I have a number of .xml files of single page lead sheets which open and display correctly in Sibelius. But in MuseScore 1.3 the chord symbols are incorrectly placed. They are attached to notes which are one or two beats to the right of the correct note. I attach one such file. If anyone can see why MuseScore is placing the chord names incorrectly I'd be grateful
| Attachment | Size |
|---|---|
| Nice work if you can get it.xml | 74.05 KB |
Comments
Looking at the MusicXML file itself, it seems the Harmony elements for the chord symbols are placed *after* the note to which they are intended to apply. Thus, the first measure says:
Note B
Harmony B7+
Note C
Normally, it seems MuseScore expects the harmony element to appear *before* the note to which it applies. At least, if I create this exact from scratch in MuseScore then export it, I get:
Harmony B7+
Note B
Note C
I can't find in the MusicXML spec where it says how this is supposed to work. Oddly, Finale Notepad seems to read your file as expected, but it also reads the output from MuseScore correctly. Which makes no sense to me. So I must be missing something...
In reply to Looking at the MusicXML file by Marc Sabatella
Marc, Thanks for looking at this. You are absolutely right in your analysis. My .xml files were generated by PDFtoMusic Pro from pdf output from Lilypond. In every case the Harmony comes after the Note to which is should be attached. Both Sibelius which I have tested and Finale Notepad which you have tested correctly interpret the position of the chord symbol. So is this possibly a bug in MuseScore? I have tested the nightly and it still behaves the same as version 1.3 in this respect.
In reply to Further thoughts... by sjha
It is possibly a bug in MuseScore. But as I said, Finale seems to be able to handle the output from MuseScore correctly, leading me to think that I am not fully understanding the problem. It could be that the file is in fact invalid in some way - that your PDF to MusicXML conversion is incorrect - but Finale & Sibelius are somehow interpreting the invalid in a way that happens to look right. We need to hear from someone who has a better understanding of how it is supposed to work.
In reply to It is possibly a bug in by Marc Sabatella
MuseScore does not seem to be parsing the '<'offset> child property of '<'harmony>. XML generated by MuseScore (1.x, at least, I don't know about the nightly builds) doesn't use this property but avoids the need for it by placing the chord symbol before the note is placed.
In reply to MuseScore does not seem to be by underquark
Aha! So it seems like this implies the correct behavior is to place the harmony element before the note to which it implies (as MuseScore does) when writing the score. The PDF to MusicXML has thus attached the chord to the wrong note, but it uses a visual offset to move it into position, creating the illusion that is attached correctly. Finale and Sibelius are honoring this visual offset but MuseScore is not.
This would explain what I see, although I am surprised the illusion is so convincing in both Finale and Sibelius - I wouldn't have thought the offsets would be meaningful across programs. And in the case of Sibelius, the chord really does seems to attach to the proper note. Maybe after applying the offset, it notices the chord symbol is above an entirely different note and internally changes the attachment?
EDIT: Oh, wow, now I see. The unit for the "offset" element is not visual, it is temporal. The "divisions" element in the file says there are 6720 divisions per quarter note, and the "offset" for the first chord is -6720. So the MusicXML is saying, "attach this harmony object one beat prior to where it actually appears in the file". A very strange way to output MusicXML, I must assume, and I can see why MuseScore might not honor it. I wonder if you have the same issue with dynamics or other markings?
In reply to Aha! So it seems like this by Marc Sabatella
Placing the note and then the harmony (chord symbol) is valid in MusicXML but a bit of an odd way to do it, IMHO. Even stranger, I think, is that the default is for the sound of any object that is offset to be set to NO which results in the object being offset visually but the sound not (by default).
http://www.musicxml.com/UserManuals/MusicXML/MusicXML.htm#EL-MusicXML-o…
So MuseScore would seem to be sensible in its creation of MusicXML but not interpreting the somewhat whacky (but valid) XML generated by other programs.
In reply to Placing the note and then the by underquark
In MusicXML a harmony elements timestamp is basically defined by the start timestamp of the next note. This explains why a harmony "attached" to a note, is written before the note in the MusicXML file. Offset is indeed in time units and by default affects only the visual appearance.
MuseScore currently ignores the offset.
In reply to MuseScore does not seem to be by underquark
It seems from this interesting discussion that the problem arises from PDFtoMusic Pro whose xml output places the the Harmony element with an offset after the note to which it should be attached. I have emailed the developers about this but as yet had no reply. In order for the PDFtoMusic Pro files to be properly opened by MuseScore with the chords in the correct place a workaround is to open the file in Sibelius and then to re-export it as xml using, for Sibelius 6, the Dolet plugin. The file thus exported is then opened by MuseScore with correctly located chord symbols.
In reply to Workaround by sjha
Which means that Sibelius/Dolet follow the good old principle: be generous in what you accept, be strict in what you generate.
I think MuseScore should do this too... Esp. the former, it seems to do the later already
In reply to Which means that by Jojo-Schmitz
Which would require MuseScore to take account of the offset which it currently ignores and use it to move the chord symbol to the correct place visually and also make an intelligent decision as to which note to attach the chord symbol. Would the developers be sympathetic to the idea of including this on the to-do list for version 2?