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!
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.
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.
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...
... in Braille this must be written as a half-note with a crescendo tied to a half-note with a decresendo.
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.
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.
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.
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.
@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:
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.
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.
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.
@shoogle, what do you think is the problem with the export ? IMHO it is somewhat convoluted but still legal and correct MusicXML (the second wedge's stop is before its start in MusicXML document order, but they are at the correct musical time, which is allowed. See https://forums.makemusic.com/viewtopic.php?f=12&t=2403&p=6547&hilit=sto…).
It does not import correct in MuseScore though, which is an import issue.
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.
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.
Hello again,
Now I'm coming with this example: https://musescore.com/user/2749876/scores/5794599
One of the examples is at bar 60, where there's a system tempo text Un peu ralenti, which appears at beat 2. The Musescore code shows a -1/4 for the location fraction, but Musescore uses a backward of the whole measure duration and puts it at the beginning, then forward to the next measure. For a correct export, after the measure rest, the should itself have an offset of -120 to shift back a quarter duration. The xml code will be more clean, and the braille transcription will go better.
Haipeng, with respect to the tempo text Un peu ralenti example, am I correct in understanding you propose to change the MusicXML encoding from the current "backup, direction, forward" into "direction with offset" ? Example of both encodings attached.
Yes, the offset for the negative location is more formal, though both work well. The offset is used for direction objects straightly, and will help braille translation more.
Lines starting with a minus sign (-) exist only in the "backup, direction, forward" file, while the one starting with a plus sign uses the "direction with offset" syntax. The other lines are the same in both files.
Yes I know the difference. The offset one is related to the direction alone, and will not cause any misplacement of other objects, and the code is more clean.
@hhpmusic, I'm sure you know the difference. My comment was aimed at others, such as myself, who are following along with interest but are not so familiar with the ins and outs of the MusicXML specifications. I found the diff useful and I thought others might too.
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.
Related to #281511: [EPIC] Braille friendly musicxml export
In reply to Related to #281511: [Epic]… 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.
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...
... in Braille this must be written as a half-note with a crescendo tied to a half-note with a decresendo.
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.
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.
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 todefault-x. What I wrote in my last comment is true fordefault-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:
<offset>element or any changes to MuseScore's internal representation.<offset>element, and potentially import it as well (by creating invisible rests in higher voices).Yes, then we should either improve it in Musesdcore 4, or make hidden rests to add hairpins for braille-friendly editions. Both works.
We should do both.
@shoogle, what do you think is the problem with the export ? IMHO it is somewhat convoluted but still legal and correct MusicXML (the second wedge's stop is before its start in MusicXML document order, but they are at the correct musical time, which is allowed. See https://forums.makemusic.com/viewtopic.php?f=12&t=2403&p=6547&hilit=sto…).
It does not import correct in MuseScore though, which is an import issue.
@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.
Hello again,
Now I'm coming with this example:
https://musescore.com/user/2749876/scores/5794599
One of the examples is at bar 60, where there's a system tempo text Un peu ralenti, which appears at beat 2. The Musescore code shows a -1/4 for the location fraction, but Musescore uses a backward of the whole measure duration and puts it at the beginning, then forward to the next measure. For a correct export, after the measure rest, the should itself have an offset of -120 to shift back a quarter duration. The xml code will be more clean, and the braille transcription will go better.
Haipeng
See also #296817: [EPIC] Support W3C MNX
Haipeng, with respect to the tempo text Un peu ralenti example, am I correct in understanding you propose to change the MusicXML encoding from the current "backup, direction, forward" into "direction with offset" ? Example of both encodings attached.
Yes, the offset for the negative location is more formal, though both work well. The offset is used for direction objects straightly, and will help braille translation more.
Haipeng
Here's a diff of the two MusicXML files uploaded by @Leon Vinken.
Lines starting with a minus sign (-) exist only in the "backup, direction, forward" file, while the one starting with a plus sign uses the "direction with offset" syntax. The other lines are the same in both files.
Yes I know the difference. The offset one is related to the direction alone, and will not cause any misplacement of other objects, and the code is more clean.
Haipeng
@hhpmusic, I'm sure you know the difference. My comment was aimed at others, such as myself, who are following along with interest but are not so familiar with the ins and outs of the MusicXML specifications. I found the diff useful and I thought others might too.
Thanks!
Created issue #298552: [MusicXML] use offset for non-spanning directions and pull request https://github.com/musescore/MuseScore/pull/5534.
Relates to #270643: [EPIC] MusicXML import/export issues too