[MusicXML] [1.1 / trunk] Problem importing triplets from XML if tuplet element is missing
MuseScore
Free music composition & notation software
Free Download
Version 1.1
Home » Forums » Support & bug reports
Problem importing triplets from XML
Submitted by jorgk3 on December 7, 2011 - 7:27pm.
Tagged:
Support & bug reports
I tried to import the enclosed XML which was exported with Encore into MuseScore.
Musescore gets confused with the triplets in measure 9. It imports them as quavers, and therefore the bar becomes "over full".
Select the first note in the bar and click on whole note. The bar is filled with a whole note but three quavers remain. Select the bar and hit delete. It deletes the content of the bar and into the next bar. The next bar is also destroyed since one can't place note any more. In short, the internals are somewhat confused.
I also enclose a score that was fixed up be deleting a few bars more so you know what it should look like.
Please refer to the forum for attachments: http://musescore.org/en/node/13996
Comments
Detailed description of tuplet issue with "oh come all ye faithful Ab.xml"
- the "confusion" happens only when using MuseScore 1.1, where a 4/4 measure is created containing more than 4/4 worth of notes
- when using the trunk the tuplet is also not read, but at least the notes are set to the correct length. After deleting the measure contents and undo, the note length are incorrect
- the missing triplets are caused by an incomplete export: Encore exports only the tuplet stop, the tuplet start is missing
Note: MuseScore behaviour should still be improved, as an inconsistent score is created.
Problem was caused by MuseScores MusicXML importers dependency on the tuplet element, which is not required according to the MusicXML DTD. Changed the importer to deduce tuplet start and stop based on the presence/absence of time-modification elements.
Fixed in the 0.9.6 branch revision 5135.
Trunk still TODO.
Partially fixed in trunk revision 5139.
Works for notes but not yet for rests with missing time-modification.
Fixed in trunk revision 5147.
Automatically closed -- issue fixed for 2 weeks with no activity.