Layout changes after Select All

• Aug 27, 2014 - 03:32
S4 - Minor

1. Open attached score.
2. 'Edit>'Select All'.

Result: The layout on pages 2-3 changes - bar 15 jumps onto new system.

Note: I see three pages.

Using MuseScore 2.0 Nightly Build (b6480b7) - Mac 10.7.5.

Attachment Size
Layout changes after Select All.mscz 9.03 KB


For the record, I see four pages in Linux, no change to any of them after Ctrl+A. Could be difference in font metric calculations (width of note characters etc). And differences in float arithmetic might account for the Ctrl+A change - but if it's repeatable for you, then I kind of doubt it.

FWIW, here is a score where for me at least, the layout of the first system changes *each time* you press Ctrl+A. It keeps going back and forth between 6 or 7 measures, and every edit you make also reverse this. Doesn't seem to be just roundoff discrepancy as the effect continues even after I change the Space setting from 1.353 to 1.360, which should be a big enough change to result in significantly different line length calculations. I suspect something is going wrong with the calculation of the space needed for the courtesy time signature. Like, if the courtesy signature is present, there is only room for six measures, but seven measure can actually fit because there won't be need for the courtesy if you fit seven, and it keeps going back and forth between these two positions. That's just a guess, though.

This resulted from the following forum discussion:

Attachment Size
Pulchra_es-13.mscz 10.58 KB
Status (old) active needs info

The score from #3 is fixed. I was never able to reproduce the problem in #1 - that score showed four pages for me on load and nothing changed on layout. This remains the case. Can anyone else reproduce with #1? For me, the measure numbers at the top left of each page are 1 (implied), 6, 13, 20, and that remains the case after each layout.

For me, no bug with score from #1 with MuseScore a92d346 (Xubuntu 14.10). However, the measure numbers at the top left of each page are 1 (implied), 6, 13, 23 (not 20).

I can't reproduce with #1 and #3, but I can reproduce under Windows 8.1 with:
The layout changes after an initial Ctrl+A, but then it no more appears to change. However, each Ctrl+A adds a step in the undo (Ctrl+Z) queue.
Windows 8.1, commit 9034a0f
Under Linux Mint 17, same commit, the layout does not change with Ctrl+A for these files, but (useless?) undo steps are added to the undo queue.

Typo - yes, I meant measure 23 for page 4.

I can't reproduce the problem with Guitar Pro test scores on Ubuntu. Doesn't surprise me so much that there might be an initial issue on import, but once the final layout is settled it should be good. So I am surprised you see the same when viewing the "ref" files.

The extra steps in the undo stack are key signatures - it appears each Ctrl+A in these case removes the existing ones and adds new ones to replace them. Maybe we can live with that.

No key signature or time signature changes on this socre, so it wouldn't be affected by the recent fixes. Instead, it is clefs that are presumably the story here.

Also, for me, I get just one shift on the first layout after load. After that is stable. Do you see the same?

Also, for me, I get just one shift on the first layout after load. After that is stable. Do you see the same?


Should I create a new issue?