Musicxml: use direction offset tag during export (and import)

• Jan 19, 2019 - 05:43
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
Tags

Comments

Hello,
I just pressed Insert after attaching the file, and all I have written in the first post has gone!
I suddenly discovered this problem. The attached shows halfway hairpins, but the Musicxml Export has no offset elements, and all hairpins have wrong position and length. The first bar, two hairpins are stacked terribly. The end of first hairpin should be shifted backward to the middle of measure, while the beginning of second hairpin should be shifted forward to the middle. The second bar, first end and second beginning should all be shifted back one beat. The values are determined by the division unit. The braille output is very dirty, and I can't determine the exact position of hairpins. This also applies to texts, especially those applies to the whole music, such as Accel. and Rit. If I make braille transcriptions of such scores, this will bring big trouble to not only me, but also all blind musicians who read my braille. My transcriptions will be misleading and harmful! As Mike and I are preparing the Open Score Braille Music Project, I think it's very important to solve this problem, even more urgent than missing system texts! Thank you in advance!

Regards
Haipeng

When exporting crescendos and decrescendos that overlap because they are on the same note as in measures 1 & 2 of the test file, the offsets are not properly exported to musicxml. This makes it impossible to import into Braille.

In reply to by mike320

Attached file Crescendo_test_default-x.musicxml provides wedge positioning according to my understanding of the MusicXML 3.1 spec: both wedge start- and endpoint have a default-x specifying an absolute position within the measure. Does that match your expectation / does that work for you ?
Note that this file was created manually, I do not yet have a MuseScore version producing this.

Attachment Size
Crescendo_test_default-x.musicxml 10.49 KB

This one will be difficult to get right due to the fact that Braille has no way to notate two hairpins on one note, so instead it uses two notes and connects them with a tie.

In other words, if given a whole-note that has a crescendo and decresendo...

double-hairpin.png

... in Braille this must be written as a half-note with a crescendo tied to a half-note with a decresendo.

double-hairpin-braille.png

So the solution may not be to use MusicXML offsets, which are notoriously unportable between different notation programs, but to use invisible half-note rests in Voice 2 as spacers to hint to Braille programs where each hairpin should go.

double-hairpin-hint.png

This is actually a better way of notating it in MuseScore because it preservers the layout on reflow operations, and I recommend it for OpenScore for this reason.

Perhaps Braille programs can already detect this hint? Please try converting the attached file to Braille and let us know what the result is.

Attachment Size
Crescendo_test_with_layout_hints.mscz 8.31 KB

It seems the Voice 2 hairpins are not exported properly to MusicXML. @Leon Vinken, perhaps you could do something about that? I think you will agree that this is a more robust solution than using offsets, which are likely to be ignored by other programs anyway.

Dear Shoogle,
In fact, the offset is the best solution, like Finale and Sibelius. The reason why it can't be exported to braille is the limitation of braille music transcription software. DZB (German Central Library For The Blind) already realized this, and they may use this value to create a secondary empty voice to put such things correctly. I also logged this in the future development of my own software if it will be put in development. No other way, thus notating in other note lengths, this may make the score different as the original, and a blind composer may be misled if he/she wants to compose for others. We should first implement this, and this is a current standard. Then we should improve the side of braille music software.

Haipeng

Unfortunately there is no agreed meaning for MusicXML offsets, so while you can add an offset to opposite ends of each hairpin there is no way of knowing that those offsets are supposed to line up - i.e. that the second hairpin starts where the first one ends. This is not the fault of Braille converters, this is a limitation that is inherent to MusicXML and affects all notation programs. MNX has the ability to specify offsets in terms of durations rather than positions on a printed page, so the trick with rests in Voice 2 will not be required when MNX is standard, but until then using invisible rests in Voice 2 is the only viable solution.

Edit: Actually MusicXML does have an <offset> element that stores a musical position in terms of durations rather than as a visual position on a printed page.

I looked into the code again. Do you mean Musescore itself only puts such hairpins by visual offsets such as positive or negative X-values? Then this is of no way to implement the Musicxml offset since the placement is totally visual instead of musical. Then this issue can be closed, or we can implement the future Musescore file format to include a precise musical location.

Haipeng

@hhpmusic, you are correct. My last comment was wrong: this is a MuseScore problem, not a MusicXML problem.

It turns out MusicXML does have an <offset> element that is different to default-x. What I wrote in my last comment is true for default-x, which is is just a visual position on a printed page (our equivalent in MuseScore is called "X offset", hence the confusion). However, MusicXML's <offset> element does indeed store a musical position in terms of musical durations, so it is suitable for your intended use-cases of two hairpins on one note, or haipins endpoints not coinciding with notes.

However, as you rightly guessed, in MuseScore hairpins must start and end on notes or rests; any further positioning is given as a visual distance from that location rather than a musical distance. This means MuseScore cannot make use of the <offset> element when exporting to MusicXML unless special handling is given to the case where a hairpin starts or ends on an invisible rest.

So the priority is as follows:

  1. Fix the bug that means hairpins are not exported correctly when they start or end on notes or rests in Voice 2.
    • This doesn't involve the MusicXML <offset> element or any changes to MuseScore's internal representation.
  2. Decide whether to give special handling to the case where a hairpin starts or ends on an invisible rest.
    • This would allow us to export the MusicXML <offset> element, and potentially import it as well (by creating invisible rests in higher voices).
    • This involves no changes to MuseScore's internal representation.
  3. Decide whether to change MuseScore's internal representation to allow hairpins to start and end at arbitrary points in a bar (i.e. not just on notes or rests).
    • This would introduce backwards-incompatible changes to the MuseScore format, so would not be viable until MuseScore 4.

Yes, then we should either improve it in Musesdcore 4, or make hidden rests to add hairpins for braille-friendly editions. Both works.

Title Musicxml Export - Missing Offset misleading output Musicxml: use direction offset tag during export (and import)
Severity S2 - Critical S5 - Suggestion

@Leon Vinken, that file does indeed seem to be exported correctly, but when I open @hhpmusic's original file and make the same changes again it is not exported correctly (the wedge start elements are there but the stop elements are missing). It seems that there is some bug in MuseScore which means that the hairpins are not fully valid until the file is saved, closed and reloaded. This is probably not related to MusicXML export.

So it seems MusicXML export is working correctly in this regard. The issue with import is tracked in #19244: [MusicXML import] reversed wedge not imported (I imagine that one is quite tricky to solve).

The remaining issues are feature requests, so I have changed this issue to a suggestion. Giving special treatment to hairpins that are attached to hidden rests is (relatively) straightforward, so we can track that here.

The idea of changing MuseScore's internal representation to allow arbitrary positioning of hairpins is more involved, so I have created a forum post to discuss this here.