[1.1] cut/paste of empty bar in 5/4 produces corruption
Not sure if there is still difficulty reproducing cases where corrupt measures - wrong number of beats - are created, but I have a score when I can reproduce it on command. As far as I can tell, there is no corruption in the score as attached, but following these steps will reproduce the problem:
1) open score
2) advanced to page 18 - the last page containing any actual notes
3) click last non-empty measure in the top (voice) staff
4) shift-click the corresponding measure in the sixth piano RH) staff to select that measure in the first six staves
5) Ctrl-X
6) click the next measure in the top (voice) staff
7) Ctrl-V
You should see the third staff - the alto saxophone staff, which containing a whole measure rest (5/4 time) only - corrupted, showing a dotted whole rest (6 beats) in the measure just pasted, and a quarter rest only (1 beat) in the next measure.
When this sort of thing has happened before, I've either never been quick enough to catch and undo my way out of it, or undo hasn't fixed the corruption, or the corruption was not reproducible. This time I caught it before doing anything else, and as far as I can tell, hitting undo got me back to what appears to my eye to be an uncorrupted state, and repeating the operation produces the same results. I hope this helps!
No partial measures here, and no tuplets, but there is a whole measure rest in 5/4 time. There were also corrupt measures earlier in the piece that I think I successfully cleaned up by deleting and re-entering them. But that was the result of more questionable activity on my part (cutting and pasting between regular 5/4 bars and ones with an "actual" time signature of 6/4 or 4/4, not always using full measures).
| Attachment | Size |
|---|---|
| 2011.mscz | 29.78 KB |
Comments
Actually, I can make this a whole heck of a lot easier. Try the attached score, which is nothing but 4 empty measures in 5/4 time. Select the first measure, ctrl-X, select the next, ctrl-V - same (corrupt) result. Issue title changed to clarify nature of bug.
Oh, and sorry - MuseScore 1.1 on Vista.
Apparently this is an expected bug...
In the code you can read the following :
//
// for cut&paste we cannot handle full measure rests:
// convert to normal rest
// (BUG: this is not possible and will fail for measure durations which
// cannot be expressed by a single rest
//
This is fixed in 2.0. I'm looking for an ugly but safe fix for 1.2. To be continued.
If it gets *too* ugly, I'd propose a different tactic - simply throw up a dialog saying that empty measures can't be copied in these cases, and make the user copy regions in smaller segments that don't contain empty measures with just a full measure rest. I'd take that over a corrupt measure any day. But I'd sure like it if full measure rests actually worked - in all time signatures. Looks like 2.0 does this, which I'll be very happy to see.
BTW, it appears the score I initially posted *does* still have a corruption in it left over from my editing of an earlier passage (measures 75-90) - the Piano LH is pretty messed up in those bars. I managed to clean up most of it from within MuseScore by pasting in new contents then deleting them, but there were still some oddball measures. A few more attempts at cleanup by deleting measures and reinserting now has me in a place where everything seems fine, except that the measure numbering is off - it goes up to 90, then the next measure is 89 again, then 90 again, and then it goes on to 91 and so on. Actually, I don't use measure numbering in the score; I'm going by the status display in the lower right of the screen. If I turn on measure numbering, they display sequentially as expected - all measure numbers are just off by two between the displayed measure number and the status display from that point on.
How dangerously am I living if I just accept that and go on? I'm actually pretty much done with everything but clean up at this point - I don't expect to be adding or deleting measures or doing any more copy & paste.
If you are done, it should be ok.
The last version in the branch has been released, focus is now on 2.0.