[Musicxml Export] - Level again exceeds 6 and stops to export

• Jan 24, 2022 - 01:58
Reported version
S2 - Critical

The attached example is quite large, sorry for this, but only this whole example can reflect what I'm saying completely. Both Musescore 3.6 and the latest 4 nightly build have this problem. The problem occurs at the end of violin II from bar 435 or later. Here slurs exceed the 6th number, and soon stop to export. At viola part around bar 425 or later, all wedges stop to export. I'm just at the end of part 1 (near bar 127), then found this problem. All slurs and hairpins and hairpin-based lines are lost in viola, cello and bass parts, and I can't do this commissioned braille transcription at all, unless I manually split violin II and viola parts into several individual parts to avoid multiple levels. However, the engraver's method to expand a part into several staves is very common, and in Musicxml 4.0 the level is now lifted to 16 or more. So I think this should be implemented, otherwise the output will be quite problematic!



Had a quick look. Issue (actually several different issues) reproduces. Would have been nice if you had found a smaller example. Both the uncompressed MuseScore and MusicXML files are > 30Mb and > 1 million lines of text :-(. Also, simply exporting as MusicXML takes a very long time.

In reply to by Leon Vinken

Sometimes to chop this large score down will get rid of the issue, so I daren't do anything upon it. I don't know if I myself can reproduce the same problem in a short example, but you can try to remove all wind+brass+percussion+keyboard staves in the Instruments dialog, leaving strings alone, to see if the issue is still here on violin 2 and below.

After increasing MAX_NUMBER_LEVEL to 16, the attached file exports to MusicXML mostly OK (the hairpin starting at tick 7/1 in track 140 never gets closed, still have to investigate that one). Maximum number of parallel MusicXML elements found:
- bracket: 3
- dashes: 4
- octave-shift: 2
- slide: 9 (!)
- slur: 7
- wedge: 7 (including the one caused by the issue mentioned above)
I'll add the increased MAX_NUMBER_LEVEL to my PR for exporting MusicMXL 4.0.

Found the cause for the "hairpin starting at tick 7/1 in track 140 never gets closed" issue. See measure 8 in the "Corni II, IV in fa" part: the hairpin duration is 3/4 in a 4/4 measure containing only a 4/4 rest. As in MusicXML hairpin start/stop times are associated with note start/stop, the exporter cannot find a suitable note stop to attach the hairpin stop to. Workaround could be to generate a backup before the wedge stop.

Assuming you are referring to the default-x and relative-x attributes generated by Finale and Sibelius, I understand those as positioning (within the score image) but not affecting the actual timing of the hairpin/wedge start or stop. Thus, IMHO, using these attributes will provide a visual approximation but will have incorrect timing information.

Fix version