Y offsets change when stave space is changed

• Jul 7, 2020 - 23:35
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.0.12237, revision: b5add95

  1. In new score add a dynamic. Note the Y offset = 4.00sp
  2. Format>Page Settings>Stave space. Note setting = 1.764mm
  3. Press down spin button four times. Note setting = 0.964mm
  4. Press OK
  5. Result: Dynamic's Y offset has changed to 2.19sp - Expected result: Dynamic's Y offset remains at 4.00sp (This is the behaviour with version 3.4.2)
  6. Format>Page Settings>Stave space. Press up button four times. Note setting = 1.764 mm
  7. Press OK
  8. Result: Dynamic's Y offset has changed to 7.32 sp(!) - Expected result: dynamic's Y offset returns to 4.00sp or stays at 2.19sp

Similar changes in Y offset occur with stave text. I have not tested other elements.

Possible but impracticable workarounds are:
a) readjust all offsets after changing score spacing, or
b) change score spacing before entering any notation.
but so impracticable they can't really be called workarounds hence the "Critical" severity.

Comments

• Jul 8, 2020 - 21:47

I understand the cause. The problem was introduced with https://github.com/musescore/MuseScore/pull/5699, but that change was actually good - we do need to call spatiumChanged for the score. The problem is the individual element spatiumChanged functions aren't necessarily doing the right thing. Values that are stored in sp units should remain as they are. Only elements stored in absolute units should be scaled.

FWIW, there is also localSpatiumChanged, which is called if a single staff is made small. Here, we actually do want to scale the values stored sp units.

Unfortunately, there are still quite a few inconsistencies here, so plenty of things that don't scale properly when scaling the score versus scaling the staff. I made a pass through this around 3.1 but I guess I missed a bunch of cases..

Reply

• Jul 8, 2020 - 21:54

You say you fixed some things around 3.1 but the problem didn't occur in 3.4.2 and we are seeing a regression in 3.5 beta. Did something come unfixed?

Reply

• Jul 8, 2020 - 22:17

Well, as I said, the current problem was introduced with https://github.com/musescore/MuseScore/pull/5699, which was only merged recently. A whole lot of things were not being scale correctly, that PR fixed those. Unfortunately in so doing, it caused those some of those things that were scaling correctly - like most offsets - to now get scaled twice, in effect.

The things I fixed last year had more to do with small staves, not actual changes to the overall staff space setting. Unfortunately there is not a lot of consistency to how these things are managed. But it is looking at the causes of this current bug that got me looking again at my previous fixes and finding cases I had missed.

Reply

• Jul 8, 2020 - 23:46

Well, that's not much of a workaround, this is critical to fix for sure. Unfortunately things were pretty broken before the PR that broke this, just differently so.

What I think I know so far:

  • manual offsets are being scaled correctly. styled ones are not (I think that's the distinction)
  • for lines, we also need to scale the line width and maybe offset2
  • manually adjusted ties & slurs don't seem to be handled correctly either
  • none of this works on undo - the scaling becomes permanent

Some things I noticed that are not handled correctly on staff scale changes are manual adjustments to arpeggios and stem lengths. I suspect beams too.

All of this is fixable, but it requires sitting down and spending time with each of these cases to work out exactly what needs to be done. Regarding undo, there is no existing undo command to change spatium it seems, but if we use undoChangeProperty (and make sure we are within a startCmd/endCmd) for each of the scaling changes we want to make, I think we're probably OK without creating any new undo commands.

Reply

Fix version
3.5.0