"Alla breve" symbol silently changes time sig values to 2/2 (regression)

• Oct 13, 2014 - 12:50
Type
Functional
Severity
S2 - Critical
Status
closed
Project

Since this commit:

https://github.com/musescore/MuseScore/commit/7ab8acd3a5a80a245f3524a5e…

a score which should be laid out like this:

misplaced_barlines_1.png

is actually laid out like this, with all the bar lines displaced:

misplaced_barlines_2.png

Analysis:

This happens because, when the score is read back from the file, the time sig (numeric value of 4/2 in this score) is forced to 2/2 because of the presence of the "alla breve" symbol. However the measures do contain notes/rests for 4 minims and the layout is scrambled.

As the symbol -- or texts -- used to display a time sig are fully configurable in the time sig properties dlg box, this change seems arbitrary and a significant regression from the configurability which was possible in 1.x and in 2.0 so far.

Occasionally (the precise steps are still unclear), the corrupt time sig is saved into the output file, if the score is re-saved, leading to significant data corruption.

Fix:

The fix is easy: it is enough to revert the aforementioned commit.

Thanks,

M.

Attachment Size
misplaced_barlines_1.png 34.29 KB
misplaced_barlines_2.png 34.9 KB

Comments

Would it not be possible to keep the fix, but simply check that the time signature really is compatible with 2/2 first? Sorry, I don't know much about how time signatures are represented, nor do I understand in which situations things were still off regarding how measure properties worked.

@Jojo-Schmitz: thanks for the detail. Still, I would say "the patch is worse than the hole", to translate an Italian saying...

I certainly agree that applying an "alla breve" time sig (from the palette) should generate a correct time sig according to the (hugely prevalent) modern European conventions (i.e. a 2/2 time sig represented with the 'C cut' symbol); the time sig props dlg box, however, allows a much wider flexibility, which is here since 1.x times.

If applying an "alla breve" time sig generates the wrong num./denomin. values, I would say the solution is to change the applying code to generate the right values, rather than erasing the user-defined settings, introducing serious inconsistencies between time sigs and measure contents and, in some cases, corrupting the score permanently.

I'll have a look...

Thanks,

M.