Corruption reading empty measure with 7/4 actual duration
Ubuntu 14.04, GIT commit: 9f62965
1) new score, treble clef template
2) drag 3/4 time signature to first bar
3) right click second measure, measure properties
4) set actual duration to 7/4
5) save
6) reload
Result: measure is corrupt.
I think the file is actually fine. What seems to be happening is that during the read, the whole rest is being converted to a full measure rest.
Comments
It was already the case in MuseScore 2.0
I say more. It's a very former issue: I can reproduce constantly in the time until 2014, May 19. The following image has been produced with this Nightly: 56177c3
The problem arises from the
if
statement at lines 254 of libmscore/cordrest.cpphttps://github.com/musescore/MuseScore/blob/master/libmscore/chordrest…
this was apparently done for compatibility with old scores. However, a file saved with MuseScore 1.3 already uses the distinction between
measure
andwhole
durationTypes.Why don't we add as an AND condition a further check on MuseScore version to the
if
statement?Something like:
score()->mscVersion() < 114(????)
where the versione number is the one corresponding to the introduction of the distinction between
measure
andwhole
durationTypes (the oldest MuseScore on my pc is 1.3, I can't verify which versions were still usingwhole
for both cases).Could it have been
// 1.12 use durationType, remove tickLen
?? Probably needs some deep digging into the old repository.
Hmm. The comment says, appropriately, that the conversion should only happens for measures that are 4/4 or less (so the rest can be assumed to fill the measure). But I don't see us consulting the measure duration at all. The final test against 4/4 is for duration(), but that's the duration of the rest itself. I think it needs to be measure()->duration(), assuming measure() is valid at this point. It might not be; we very possibly haven't actually added the rest to a segment yet.
After a bit of archeology, the following commit added this code https://sourceforge.net/p/mscore/code/4345/
Some more here
https://sourceforge.net/p/mscore/code/4222/
And last bit
https://sourceforge.net/p/mscore/code/4209/
As I feared, at the point where this code is hit, the rest has not yet been added to a segment, so there is no way to know if the current measure is in fact 4/4 or less.
Without knowing exactly what conditions might have led older versions to write a whole rest when a measure rest would have been preferable, I'm inclined to just remove this whole conversion, or relegate it to sufficiently old scores only. I don't know if there are conditions where 1.3 would write rests that way, but I haven seen any.
Because of the changes here https://sourceforge.net/p/mscore/code/4209/ (regarding mtick) I would go for <1.12, which in any case we don't support in 2.0.
Fixed in 93d1b4893d
Automatically closed -- issue fixed for 2 weeks with no activity.