Bar numbers incorrectly positioned

• Dec 1, 2012 - 17:15
S4 - Minor

1. Open attached score (produced in 1.2).

Result: The bar numbers aren't correctly positioned.

Discussion: Compare with LilyPond.

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


I think the bar numbers shouldn't go past the bar line and not be as high?

Are there recommendations somewhere (e.g. 'Behind Bars')?

Isn't this just a question of your bar number text style settings?

Looking at the published scores I have access to, the bar numbers are all over the map - different sizes, different positions. More of them are like MuseScore (overlaping the bar line, or even all the way to the right) than like LilyPond (all the way to the left of the bar line). So there doesn't seem to be any universal standard for this. But I wouldn't be surprised if Gould doesn't make recommendations, and perhaps the default text style could reflect whatever they are.

I think you might be right Marc.

This maybe another report: Regardless of position, if another digit is added, I think the final digit should always be in the same position with all the other numbers moving to the left, rather than into the score?

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

Attachment Size
Four digit bar numbers.mscz 7.36 KB

This should also be a matter of your text style settings. I'd expect any template/style that places the numbers to the left of the barline to be right-aligned, and any template/style thatplaces the numbers to the right of the barline to be left aligned.

More feedback on this?

As Marc noticed, MuseScore default to center the measure number on the barline. A user can go to Style -> Edit text style -> measure number to right or left align the measure numbers, see attachement.

Do we want to change the default?
Finale defaults to left aligned…
Sibelius 7 defaults to left aligned
Lilypond to right aligned

Attachment Size
Four digit bar numbers.mscz 8.32 KB

My numbers are partially obscured by the top left corner of the measure. I'd like to at least make them visible no matter where they are.

BTW. You must be using 2.0. Those of us on 1.3 can't view your attachment. Dialog box comes up saying my version is too old.

Yes, in general, the issue tracker is only used for tracking issues with 2.0, since thee will not be any more 1.x releases (famous last words, I know).

If you're having problems with measure numbers in 1.x, it's better to ask in the forums. Then if it is determined it is really a problem and that it still exists in 2.0, then we post to the issue tracker.

Normally, measure numbers should not be obscured, but that would depend on what templae you are using and/or your stle settings. So do post abiut this with an example in the forum if you are finding cases where measure numebrs are obscured even using default settings - that is, when creating a score from scratch or from a MuseScore-supplied emplate.

Currently there is no way in MuseScore to position the measure number relatively to the clef. Measure numbers are relative to the top of the system. Making them relative to the clef will probably open a can of worms. If it's what we need, let's open a feature request.

The only thing we can easily play with is the default vertical position of the measure number relative to the staff (in Style -> Text -> Measure numbers) and the look of the G clef with ottavation. What do you propose?

* We change the default Y of the measure numbers, it will make them quite high for a bass clef.
* We change the look of the ottavation and put it closer to the clef.
* We do nothing. We close this bug. If someone makes a score with a picollo as first instrument and go over 999 measures, he will to modify the text style manually.

Well, there could be another option here, and that is to change the default to be right aligned rather than centered, with a position chosen to clear the "15". Or leave them centered but add just enough of an X offset so that four digit numbers clear the 15 horizontally. I have no strong feelings at all about how measure numbers are presented by default and wouldn't object to that change. But I also have no problems with doing nothing here and letting the rare user who encounters this worry about it.