Reading back measures of irreg. length might corrupt time sig map
Context: r. f2c2e718dd (2012-09-04) self compiled under Ubuntu 11.10, Qt SDK
Steps:
1) Load the attached score
2) Look at the properties of the last measure with notes (meas. 11 of last page)
Result: The measure has a nominal duration of 3/8, but it is in a 4/4 section. All the following measures have the same incorrect nominal duration (which is the nominal duration of the previous section).
Notes:
I have been unable so far to replicate this behaviour in a simpler score, but I cannot detect anything strange either in the displayed 'surface' or in the mscx source of the attached score.
Also, those measures with a wrong 3/8 nominal duration had originally the correct 4/4 nom. duration when entered. Only after saving and re-opening, did the nom. duration change.
(The score is not finished yet, so do not take it as 'real' edition)
Analysis: as far I can understand, (part of) the problem is in reading back measures with the "len=..." attribute in the <measure> tag. The attribute is read before any time sig and generate one time sig map entry for the irregular measure and one for the next measure (assumed to be regular), both with the current (=previous) nominal duration.
When the time sig is eventually read, the first time sig map entry is updated but the other is not; so, the previous time sig is carried over.
Once the score read, Score::fixTicks() is sometime able to fix this but in some cases, like this score, it is not.
I have a fix ready to be posted to Github.
Thanks,
M.
Attachment | Size |
---|---|
Boismortier_31_1.mscz | 19.47 KB |
Comments
Merged in 54ab279d12
But not sure it solved the problem. Last measure is 7/8 actual duration and looks correct (4 8th + a dotted quarter). The measure after is 3/8
The measure after the repeat is 3/8 as actual duration which, as far I can remember, may well be correct (of course, it isn't correct musically, but the piece was not finished yet and that measure needed intervention anyway; in fact, after this patch, I have been able to finish the movement without problems.).
The point was about nominal duration: it was wrongly read back as 3/8 and it is now the correct 4/4.
So, as far as I can tell, this specific issue is fixed.
M.
Automatically closed -- issue fixed for 2 weeks with no activity.