Deleting tuplets causing crashes and strange behavior
Hello,
I am running into strange issues when manipulating tuplets. I am working on an arrangement for a student. When I try to delete a tuplet, it will erase the whole beat from the measure (rather than replace with rests) and not permit me to input anything into the missing beat.
Other times, the program will simply crash. Upon relaunching, it will then tell me that the score is corrupted. I restore my session, save to a new file, and the process begins anew.
Thank you for your help.
| Attachment | Size |
|---|---|
| Meditation_from_Thais-arranged-2.mscz | 16.14 KB |
Comments
Can you reproduce the problem in that score? If so, can you explain the steps? If this is after the corruption (which seems the case), can you attach a score before the corruption and explain how to recreate it?
In reply to Can you reproduce the… by mike320
Here is the original score, as well as the version that my program said was corrupted.
If I delete the tuplets first thing after opening the score, there is no problem. It replaces the tuplet with a rest. However, after editing pitches, removing measures (using 'remove from range'), or other edits, it will begin to happen again.
I first noticed this trying to remove the quintuplet in mm. 3, but it will happen to any tuplet once the problem manifests.
Measure 21, staff 1 incomplete. Expected: 4/4; Found: 26/24Exactly the measure where you're working on the tuplet. Your issue is not as much with editing a tuplet as it is with editing a corrupt score (in which case anything might happen, including crashes).
First fix the corruption itself, then reopen the score and all will be fine. I've fixed it for you by inserting a new measure before m22. Typing in the contents of m21 (please check if correct) then selecting m21 and removing it.
Now as mike mentioned, it would be extremely valuable to use if you know/can reproduce how to create the corruption, so we might be able to prevent it in a future update.
In reply to Measure 21, staff 1… by jeetee
The original score is posted in the comment above--as far as I can tell, it is editing the tuplet which creates the corruption. Each time it happens, I can close and reopen the score and it will work for a while. Then the problem crops up again and it will tell me the new version is corrupt again, too.
In reply to The original score is posted… by cmo87
I think I now have a grasp on what you are doing. I'll try to duplicate the corruption in that score.
In reply to I think I now have a grasp… by mike320
If I ctrl+delete mm17-18 then delete the triplet in the new m50 I get a corruption using the Meditation_from_Thais score. Perhaps jeetee can now run it through the debugger and see what's happening. We can then collaborate to make a useful bug report.
Hmm, I seem to remember fixing this a couple of years ago. Ah, it appears that a very important line from that fix has gone missing. This means that #272172: Remove tuplets after inserting measures causes corruption/crash is an issue once again, and has been since ec3be9a. To solve this, we'll just need to add that line back in.
In reply to Hmm, I seem to remember… by mattmcclinch
Curious, I wonder if there was a reason Werner deleted it?
In reply to Curious, I wonder if there… by mike320
He must have thought that the tuplets' ticks did not need updating. But clearly they do. Besides, updating the tuplets' ticks was the entire reason for any of the code added in commit 4e14bbc. Otherwise, none of it does anything.
In reply to He must have thought that… by mattmcclinch
My concern was that he removed it to prevent another bug. I'm not at all familiar with the code so I have no idea.
In reply to He must have thought that… by mattmcclinch
Replacing ticks with fractions was what solved almost all corruptions that happened when dealing with tuplets.
Not in this particular case though it seems...
In reply to He must have thought that… by mattmcclinch
I can confirm that adding that line back seems to fix the issue, at least I can't reproduce the issue using @mike320's description above anymore
In reply to Hmm, I seem to remember… by mattmcclinch
@mattmcclinch are you going to work on this then?
Really strange that this problem didn't come up much earlier, it should exist since (before) 3.1beta, some 1 1/2 years
In reply to That commit also added https… by Jojo-Schmitz
Sorted with https://github.com/musescore/MuseScore/pull/6696 being merged
In reply to Hmm, I seem to remember… by mattmcclinch
My best guess is this was simply a case of code crossing, Werner had perhaps already started working on this code before the fix and the fix never made it into his branch. Or a random oversight.
I've said this before, but it bears repeating: the tick-to-fraction change was really big and it's incredible to me it didn't break more than it did, while improving so much along the way. Nice "parting gift" from Werner :-)