Values in sp unit don't remain unchanged after changing spatium

• Apr 14, 2017 - 19:09
Reported version
3.0
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore
Tags
3.0alpha
3.0alpha-06
layout

Windows 10, GIT commit: de38cce

Discovered while working on #187151: Hairpins shifting out of position on systems containing ties from stem. Not a recent regression in general - this goes back to before release of 2.0. For hairpins in particular the problem was introduced a little later than the others, but it was definitely there by 2.0.3.

1) create a score with a time signature, a two-note quarter note chord with an arpeggio, and a hairpin
2) apply a user offset to the time signature, chord stem, arpeggio, and hairpin
3) change spatium value

Result: the user offset for those elements is altered. Basically, we aren't scaling them, because we override spatiumChanged() but don't call Element::spatiumChanged() (or whatever the parent is).

Comments

• Apr 14, 2017 - 19:47

This also occurs for certain elements on a "local" spatium change - that is, altering the staff scaling in Staff Properties. Some elements will have their manual positions scaled correctly, others don't. For instance, elements attached to chords (like arpeggios, dots, accidentals) don't. Hairpins actually do, but the *default* position for hairpins on scaled staves is not calculated correctly it seems. That's another bug - on staff scaled to 200% add a hairpin starting with a downstem quarter note, and compare to the results on an unscaled staff. For the unscaled staff, the hairpin starts at the stem; for the scaled staff, it starts to the right.

Reply

• Apr 22, 2017 - 18:58

My guess is that this same fix will be relevant in master, but I will check into that after 2.1 and I have my build system set up for master again.

Reply

• Feb 12, 2020 - 08:36
Severity S4 - Minor ⇒ S2 - Critical
Frequency ⇒ Few
Regression ⇒ No
Reproducibility ⇒ Always
Workaround ⇒ No

Still broken in 3.4, considered critical because there's no easy workaround to revert the manual offsets and it is especially annoying when lots of elements have been moved.

Reply

• Feb 12, 2020 - 10:09
Title Manual positioning altered for certain element types on spatium change ⇒ Manual positioning altered for all elements on spatium change

Sad, spatiumChanged() isn't even called after changing spatium.

Reply

• Feb 12, 2020 - 10:51
Title Manual positioning altered for all elements on spatium change ⇒ Values in sp unit don't remain unchanged after changing spatium

Reply

• Feb 12, 2020 - 15:16

(I started to post this before then apparently didn't, apologies if it shows up twice, cross-posting with myself)

FWIW, the original issue was about a few corner cases where spatiumChanged() wasn't being handled for a few specific element types. Right now it is much worse, not being called at all. Still completely flabbergasted this hasn't been noticed before since it has apparently been broken ever since 3.0

Reply

• Feb 14, 2020 - 08:45
Status PR created ⇒ fixed

Fixed in branch master, commit 71771cd4e3

_fix #188061: values in sp unit don't remain unchanged after changing spatium

This is simply because Score::spatiumChanged() isn't called after applying changes in Page Settings dialogue. It is called for the preview score in the dialogue though, so the preview score has the correct display, but not the main score._

Reply

Fix version
3.5.0