MusicXML import - attempting to fix badly read triplets causes crash

• Dec 11, 2018 - 09:41
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore

Steps:
Import the xml file
in the third bar, on the third beat, click on the little "3" digit (the upper one)
press delete -> crash

(the musicXML file was exported from a music OCR software)

Attachment Size
O_Mati_vznesena.xml 239.71 KB

Comments

• Dec 11, 2018 - 16:08
Status active ⇒ needs info
Priority ⇒ P0 - Critical

Which build are you using (see Help / About, click the button next to "Revision" and paste here).

I don't see a crash in current build.

Reply

• Dec 11, 2018 - 17:36

Picture added to show exactly what to click on (what thing to select before you press delete key)
It crashes when I use this:

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0, revision: 6ba431b

also crashes with the newest one I've just downloaded and with 2.3.2
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4424, revision: 01e2f04

Attachment Size
Capture.PNG 32.63 KB

Reply

• Dec 18, 2018 - 11:13
Priority P0 - Critical ⇒ P1 - High
Workaround No ⇒ Yes

Dividing by 0 is not good indeed, but not as critical as other issues. So need to be fixed asap after release. Workaround is to edit and fix the malformed triplet in the musicxml file.

Reply

• Dec 18, 2018 - 19:04

This issue is not as serious as it looks:
- it happens only for a malformed tuplet (in which case the MusicXML importer fails to correctly initialise all tuplet data structures)
- it happens only the first time after loading the MusicXML file (saving in MuseScore format and then loading the MuseScore file solves the issue)

Furthermore, the fix is not entirely trivial and will take some time to correctly implement

Reply

• Jan 13, 2019 - 12:14

After investigating the various ways in which a malformed MusicXML tuplet crashes MuseScore, my conclusion is:
- the structural solution should be to always create a complete tuplet (filling with rests if necessary) even if the tuplets are incomplete or malformed in the MusicXML file
- this is not just "non-trivial", but actually a quite a complex change, requiring a redesign of the note handling in the MusicXML importer
- nevertheless I feel this is worthwhile, as the note handling code currently is overly complex and should be improved

Reply

Fix version
3.3.0