Attaching grace note to first note of triplet corrupts score

• Dec 25, 2018 - 19:54
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

I have a score that looks like (see screenshot). I save it (see attachment). When I reopen it, the "3" is missing from the triplet. If I delete the grace note and then simply UNDO that deletion, the 3 reappears (and with bracket "arms" that I'm not sure are really necessary, as seen in screenshot).

If the grace note is moved down to be a bass drum note (which is normally the second voice), then something even worse seems to happen. On reopening I am told that the file is corrupted and the measure contains 9/8 beats instead of 4/4.

Attachment Size
Screen Shot 2018-12-25 at 11.50.58 AM.png 61.83 KB
Test.mscz 6.26 KB

Comments

I think this and #280547: tuplet brackets connected to two staves, moved up a staff, causing score corruption and crashes might be the same. I bet you can find the tuplet numbers - look a few staves down from where the actual tuplet is. It's not just grace notes, either. Copying a tuplet makes it go wonky. Pasting a tuplet goes wonky. Adding a staff and then some notes to it makes them go wonky.

I think it might be just anything that affects layout. I've also gotten duplicates of dynamics, lines, texts, hairpins on staves above the staff they're duplicating from.

Regression No Yes

I'm hitting this, too. Upon opening the file, I get the corruption notice, with the following detail

Measure 1, staff 1 incomplete. Expected: 3/4; Found: 21/24

Example file: triplets+grace_corruption.mscx

Seems to be easily repeatable (this trivial example file was built from scratch). Unfortunately, my 196 measure score is also corrupted in this way.

In reply to by mcx

The title of this issue should really be changed--it's not just losing the "3" from the triplet--it's corrupting the score.

One related note: Using Cmd+Right to select the whole measure actually selects into the next measure. I guess this is just a symptom of the corruption.

Also, I think saving and reopening might be required to repro.

OS: macOS 10.14, Arch.: x86_64, MuseScore version (64-bit): 3.0.0.20137, revision: c1a5e4c

Title attaching grace note to first note of triplet makes the "3" sometimes disappear attaching grace note to first note of triplet corrupts score
Title attaching grace note to first note of triplet corrupts score Attaching grace note to first note of triplet corrupts score

Steps from scratch:

  • First scenario: single triplet/grace note (the "3" disappears after saving)

1) Load this test file: triplet.mscz
2) Attach a grace note to first note of triplet
3) Save/Exit
4) Reload
You get this result: the "3" is lost, but no corruption (file at this step: Grace triplet save.mscz)
3 display.jpg

  • Second scenario: 2 triplets/grace note (results in corruption after saving)

1) Load the same test file, but after adding another triplet in the score, no matter where: 2 triplets.mscz
2) Add a grace note first note first triplet
3) Save/Exit
4) Restart
You get a corrupt score: Grace 2 triplets save.mscz
trip.jpg

All of the triplets in this issue to this point have been made up of quarter notes. In testing, I have found that tripets made of quarter and 16th notes lose their numbers as brackets when reloaded, but the beats in the measure are correct. I haven't tested, other tuplets or other note durations.

From what I see, when the tuplet and the grace notes are created, the grace notes are not added as elements of the tuplet, but only their parent notes. However, when the tuplet is read from the file, grace notes are also added to the list of its elements, as well as their parent notes; this could be the cause of the corruption.
I don't think it is possible to make a tuplet of grace notes, so maybe we could solve the bug by preventing a grace note to be added to a tuplet during file reading (the grace note would be added only to the parent note, which on the other hand is added to the tuplet, so no information lost should occur).

Fix version
3.0.1