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

• Jan 24, 2022 - 01:58
Reported version
3.6
Type
Performance
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

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!

Haipeng

Comments

• Mar 8, 2022 - 20:16

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.

Reply

• Mar 9, 2022 - 13:17

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.

Reply

• Mar 10, 2022 - 21:02

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.

Reply

• Mar 11, 2022 - 07:12

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.

Reply

• Mar 12, 2022 - 08:26

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.

Reply

Fix version
4.0.0