relative-x tags exported to MusicXML incorrectly

• Dec 3, 2014 - 17:16
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore
Tags
musicxml

Ubuntu 14.04, GIT commit: 28b5daf

It appears we may be exporting relative-x incorrectly in the one case where we still use it: chord symbols. For one thing, we only include this tag for positive offsets. Not sure why, maybe a holdover from the old days when such offsets were the only way to create the illusion of a chord on a beat with no notes. It's probably worth continuing to support that, I guess, even though we now support chord symbols on otherwise empty segments.

But the real problem, apparently, is that the units are wrong. I don't understand how this is supposed to work, but see the following: http://musescore.org/en/node/40611. We seem to be putting out a relative-x value that is much too large? Not really sure what "tenths" are supposed to represent, or if we should really still be using relative-x rather than offset.

Comments

• Dec 4, 2014 - 15:18

Thanks. So it seems we would need to divide the value we are calculating by the current "spatium" value. Not positive how all this works in MusicXML, and also, still not sure using relative-x in the first place really makes sense - we could be using offset, or not using anything at all. Also not sure we need to handle positive offsets different from negative, although I have this thought that maybe at once time I might have had something to do with that. Hmmm. Anyhow, I'm hoping maybe Leon can weigh in.

Reply

• Dec 4, 2014 - 20:47

The code that emits relative-x for harmony element has been in place unchanged at least since 1.2. I suspect it has been broken by one of the big redesigns in 2.0. Handling positive and negative relative-x differently makes no sense anyway.

It looks like MuseScore handles relative-x incorrectly both on import and export, as the exported value is definitely incorrect, but the result is OK on import.

I cannot remember why relative-x is used at all, as MuseScore typically does not export any layout information and doesn't import a lot of it.

Both default-x and relative-x are integer or decimal numbers in tenths, which results in basically unlimited precision, while offset is an integer in divisions, resulting in limited precision.

Quoting the MusicXML spec:
The tenths type is a number representing tenths of interline staff space (positive or negative).

One more thing to fix ...

Reply

• Dec 4, 2014 - 22:32

Actually, I don't think anything changed at all - I think it was just as broken in 1.3, and indeed, has been since further back according the original file. The code is simply not accounting for spatium.

I am guessing the only reason we ever exported relative-x was to allow you to create the illusion of a chord on beat 3 of an empty 4/4 bar, back before it was possible to do this directly (1.1, I believe). Since we generally don't deal with offsets otherwise, I propose we simply remove the relative-x code from both improt and export of chord symbols. I'm happy to do that myself.

Reply

• Dec 5, 2014 - 07:03

Fine with me, feel free to do so whenever you want.

I have more than enough bugs I'd like to fix before the next beta and not enough time ...

Reply