MusicXML annoyance - Chords in the wrong place
When importing MusicXML files into Finale, the chords sometimes end up in the wrong place - often outside the page. I have traced the error to the “relative-x” attribute: Debug info:
C
dominant
The gurus at Makemusic told me:
This MusicXML relative-x value is telling an importer like Finale to move the chord symbol to the right by 82 staff spaces – more that the size of two entire staves. This is most likely incorrect, and could easily be outside the page if the chord appears near the end of a system. Adjust the relative-x value accordingly, or remove it altogether.
The reason I report it here is the contents of the MusicXML header:
<?xml version="1.0" encoding="UTF-8"?>
Oh Lady Be Good
George Gershwin
Ira Gershwin
All Rights Reserved
MuseScore 0.9.5
2010-01-06
ProxyMusic 2.0 c
Attachment | Size |
---|---|
Oh Lady Be Good.mxl | 4.38 KB |
Comments
There are 3 chord symbols, one in each measure 32, 33 and 34, that have had their x position adjusted. Even a small adjustment is showing a very large positive relative-x value for the symbol. So dragging a chord symbol partially to the right in a measure results in a relative-x of 270.
I honestly do not know what scale this value has, so I will let someone else answer this.
For now, you can export the XML, edit in a text editor, find the relative-x values and set them to "0" to reset the value. This will result in chord symbols overlapping and hard to see.
MuseScore 0.9,5???? The current released version is 1.3; all current development is towards 2.0.l Can you reproduce this in something more current?
If so, please post the MSCZ file - from before the export. But I suspect this is a bug that was fixed several years ago.
EDIT: Nope, I'm wrong, I can reproduce this in 2.0 builds as well. Any chord symbol dragged a small amount, when exported, gets a too large offset. I will file this to issue tracker.
In reply to MuseScore 0.9,5???? The by Marc Sabatella
Marc, I wouldn't dismiss this so quickly. Moving a chord symbol to the right the width of 5 standard staff lines results in a relative-x of +450. I would need to create a sample file and load into Finale at home, but this does seem quite large.
For example, the entire measure 1 width in my sample file is 456.99, but the chord shift I did (less than a quarter of the measure) is 450. But I don't know if the scales of the two numbers is supposed to be the same.
In reply to MuseScore 0.9,5???? The by Marc Sabatella
Actually, I partially take that back - I could reproduce in Beta, but not with current build. I don't get any relative-x value in the harmony objects at all any more, even if they have been dragged. Not sure if that itself is intentional or not, or if there is a way to force relative-x values to be included. I don't see anything obvious in Edit / Preferences / Export.
EDIT: our posts are crossing. I do see the bug in 2.0 Beta 1, but not in current builds. Can you verify?
In reply to Actually, I partially take by Marc Sabatella
I certainly can, in 8fb84d9, 2 revisions old. Are you saving in XML?
I just created a piano score, added a line break on measure 4, added some notes and some chord symbols, dragged the symbols partways to the rights (with Ctrl for constrained dragging) and exported as XML. The relative-x is there.
In reply to I certainly can, in 8fb84d9, by schepers
Interesting. As I said, I can see this in Beta, but not in my current build - I get no relative-x tag at all. What do you have checked in Edit / Preferences / Export?
Also, do you have similar issues with other element types?
In reply to Interesting. As I said, I by Marc Sabatella
I've updated to the latest git. Windows 8.1u1 64bit.
Export is defaults, "export layout" and "export all system and page breaks" enabled. I will include an MXL that shows the issue. The chord symbols in measure one have been dragged to the right, the first between the first and second note, the second one to the final note.
In reply to I've updated to the latest by schepers
Weird, I can now sometimes get relative-x to show up, other times not.
Could you post the actual MSCZ file? It's kind of too late to tell what's going on given only the exported XML. Also please try with other element types, not just chord symbols.
In reply to Weird, I can now sometimes by Marc Sabatella
I didn't save an MSCZ as it seemed pointless, I simple created the sample and exported immediately. I will attach new ones...
I tried dragging a few other things (title, lyrics) but the drag didn't survive XML export/import. I will try others.
In the sample file, the chord symbol D is dragged from note 1. In the MSCZ file it shows this harmony as pos x="6.15" y="-2.5", in the XML it's relative-x="410.00".
In reply to I didn't save an MSCZ as it by schepers
I was still not understanding why some chord symbols drags result in relative-x tags being written but others don't, so that's why I wanted to see your MSCZ - to see what you might be doing differently. Turns out it's simple - drags to the right get relative-x, drags to the left do not :-).
I have checked the code, and it appears relative-x is *only* used for chord symbols - no other element types. There is also an "offset" tag that is sometimes used, and some notes in the source that these are mutually exclusive, and that we still need to work on our "offset" support. For most elements, it appears we do not bother writing offset tags for moved elements, although I am not at all understanding when we might or might not.
But I think I know enough to file an issue now.