Reading back measures of irreg. length might corrupt time sig map

• Sep 4, 2012 - 22:17
Type
Functional
Severity
S2 - Critical
Status
closed
Project

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

Status (old) active fixed

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.