'Measure numbers every system' should place numbers after split measures

• Sep 10, 2018 - 14:53
S4 - Minor

If the first measure of a system is excluded - most commonly, when that measure is the end of a split measure that begins in the previous system - the 'Measure numbers every system' option simply skips that system. This is surprising behavior, as the standard practice I've seen in typeset music is to number the first normal measure of each system.

Attaching an 1800s folk tune which needs split measures for choral singing because none of the phrases starts on the downbeat. The result is that 'Measure numbers every system' doesn't place any measure numbers at all. Manually overriding the numbering achieves what one would expect 'Measure numbers every system' to do by itself, as in the second attachment.

Attachment Size
handcart.mscz 14.3 KB


If I load your score into MuseScore 2.x, I can immediately see what you are talking about. Version 3.0 has the same issue, but it is not immediately obvious, since it lays out the score such that each system begins with a complete measure. But if I add system breaks where version 2.x separated the systems, the measure numbers will indeed disappear.

Measure numbers are also incorrect, no? Status bar shows different bar number comparing to ones I see above the barlines at the start of the systems.

Status (old) fixed needs info
Status fixed needs info

Reopen for incorrect measure numbers discussion. Maybe, it is worth creating another issue.

All of the pickup measures are excluded from the measure count as far as the printed score is concerned, so the measure numbers above the barlines are correct. But as far as internal representation is concerned, and the TimeSigMap in particular, each of these is its own separate measure. The status bar displays the measure number calculated by TimeSigMap::tickValues(), which does not have access to any score elements.

The "incorrect measure number" question - which is apparently about the mismatch between the status bar and the numbering - seems to me to be entirely unrelated. I'd recommend this issue be closed as fixed again and a new issue opened for the unrelated problem.

Note issue 279767 which asks whether the fix for this bug was intended; yes it is.