Positions above/below staff not scaling with staff size

• Feb 19, 2019 - 19:05
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore
Tags
smallstaves

Elements like staff text or dynamics whose default position above or below the staff is set in spatium units are not being scaled. So, a staff text is always 3 full size sp units above the staff regardless of the size of the staff. This is a regression from 2.3.2 and looks bad.

I see a few existing issue reports on other things that do not scale correctly on small staves:

Also, symbols attached to individual notes should probably scale with the note - see #280641: Scale notehead parentheses with notehead

And some elements of fretboard diagrams don't scale at all even with the score spatium - see #283679: Fretboard diagrams: symbols on top of diagram, and position number do not resize when scaling is changed

Comments

• Feb 19, 2019 - 20:42

Manual adjustments also do weird things, still looking.

Another thing - the skyline for small staves is wrong, the barlines are extending down as if the staff was full size.

Reply

• Feb 19, 2019 - 21:24

The same behavior exists for text elements as well as lines and fermatas, so I'm thinking this needs to be solved at the element level.

It seems to me there is a fundamental choice to make here - do we record all offsets as unscaled values (which we do currently) but scale them when drawing and adding to skyline, or do we record then in scaled values then unscale them when displaying the values in Inspector, and probably also do the conversion on read/write?

Feeling a little more architectural than I want to deal with, so I'm hoping someone takes it up from here. Because as it is, small staves are pretty severely broken.

Reply

• Feb 20, 2019 - 01:40

The answer here is pretty straightforward (but the implementation may not be of course). When dealing with small staves the spatium unit itself should be scaled.

To see why this is:

  1. Double-click on a rest on a small stave
  2. Press Ctrl+Down to move the rest down by a single staff space.
  3. Look at the Y offset displayed in the Inspector.

On a normal staff the Y offset would now read 1sp, but for a small staff it reads 0.7sp. This is because small staves are 70% of normal size by default, but it is unintuitive since the rest moved by one staff space. In my opinion it would be much more intuitive to display "1 sp", or even display a new unit like "1 ssp" (for "1 scaled spatium" or "1 small spatium").

However, the current behaviour is not just counter-intuitive, it is also objectively wrong. To see this, do either of the following:

  • Make the stave large again.
  • Go to Format > Style > Sizes and adjust the small stave size to anything other than 70%.

The rest's Y offset remains at 0.7 sp in both cases (i.e. it is not updated to reflect the new staff size) so now it is drawn in the wrong place. This shows that the value stored must be unscaled (i.e. "1 sp") otherwise it is necessary for the user (or an algorithm) to manually scale the offset of all elements individually. Users either won't bother doing this or they will forget to do it for some elements. An algorithm would probably forget some elements too (or rather the programmer would) and it could lead to rounding errors.

If the stored value is not the same as the displayed value that can also create rounding errors, so since the value stored must be "1sp", the value displayed in the Inspector must also be "1sp".

TLDR

  • It is essential that offset values are stored unscaled so that the user can easily adjust scaling later on.
  • It is desirable that the value displayed in the Inspector is also unscaled.
  • All scaling must be applied at the point when objects are actually painted on the screen.

Reply

• Feb 24, 2019 - 13:29

All the elements in @Nagrom13197's example that are drawn big on the small staff should indeed have been drawn small, but I think there are certain other elements that should be drawn full size regardless of which staff they belong to. This includes bar numbers, rehearsal numbers, tempo markings and system text (as opposed to stave text). Basically anything that logically belongs to the system rather than the staff should be drawn full size regardless of whether the top staff happens to be small. There might be some grey areas when it comes to things like chord symbols.

Reply

• Mar 27, 2019 - 02:51
Status active ⇒ PR created

https://github.com/musescore/MuseScore/pull/4827

This implements things the way it was in 2.x - so, an offset of 1sp will actually read in the Inspector as 0.7sp, and be written this way. This is how things have always worked, I didn't want to change that, and I certainly didn't want to break compatibility. But it wouldn't be hard to change the Inspector display to scale the spatium values for display, and keep the read/write the same.

Reply

Fix version
3.1.0