Staff text unexpectedly repositions when "Set to style" is pressed for different element

• Dec 21, 2018 - 12:02
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4725, revision: d32f837 (edited)

Open the attached score (created in 2.x) and take the reset. Notice the staff text in measure 1, custom-positioned below the treble 8vb staff.

  1. Select the dynamic in measure 9 and move it forward with the horizontal offset in the Inspector.
  2. Press the "Reset to style" button.

Expected result: Only the position of dynamics should change.
Actual result: The staff text in measure 1 is repositioned above the 8vb treble staff.

Attachment Size
chansonette_2.x.mscz 32.94 KB

Comments

• Dec 21, 2018 - 17:11
Status active ⇒ needs info

I cannot reproduce with a build from today or even with the last beta, which is older than your build. Is it possible there is a step missing in your description?

Reply

• Dec 22, 2018 - 10:17
Status needs info ⇒ active

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4744, revision: 36e6246

Still the same result with this nightly—and the position of the staff text in question doesn't revert on UNDO. Other changes to the score can also lead to the staff text unexpectedly shifting: e.g. In "Style > Beams", press the "Beam distance" up arrow once.

P.S. Has "Open issues" been included by mistake as an option in the user dropdown menu? See #279853: Remove "Open issues" option from "Status" in user posts.

Reply

• Dec 22, 2018 - 17:12
Status active ⇒ needs info

Until a developer is able to reproduce the issue, we still need information, so please do not keep changing the status field. And I remain unable to reproduce it in a current build. The steps seem clear enough that I cannot guess what you might be doing differently than I, but it fails to fail for me. Can you create a screenshot video?

Reply

• Dec 30, 2018 - 15:13
Priority ⇒ P0 - Critical

FWIW, now it reproduces for me. I can also reproduce a similar scenario from scratch:

1) empty score
2) click first measure rest
3) Ctrl+E to add expression text
4) enter some text, press Esc
5) Format / Page Settings
6) change staff space
7) OK

Result: expression text jumps above. In fact, I can also reproduce by replacing steps 5-6 with just about anything that forces a full relayout. But, if I select the expression text and press "X" twice, this seems to lock in the position. My guess is we are failing to mark the property unstyled.

Reply

• Dec 30, 2018 - 15:19

Also, expression text entered from the palette works fine. So I think I finally have something of a handle on this:

  • when entering expression text via shortcut, we get the offset wrong (not necessary related, but annoying :-) and also fail to set unstyled
  • we also fail to set unstyled during the automatic detection of placement on 2.x import

Reply

• Dec 31, 2018 - 17:35

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

Sorry, there was a mistake in step 2 of the original instructions:

  1. Select the dynamic in measure 9 and move it forward with the horizontal offset in the Inspector, or arrow key.
  2. Press the "Set as style" button.

Expected result: Only the position of dynamics should change.
Actual result: The staff text in measure 1 is repositioned above the 8vb treble staff.

Reply

• Dec 31, 2018 - 20:35

Indeed, that was how I was finally able to reproduce. It's actually anything that triggers a full score relayout I think.

Playing with the code, the issue is definitely about not setting the UNSTYLED flag, and the fix is as simple. Similiar issue for lines (hairpins etc) but unfortunately same fix doesn't quite work because of confusion between the "segments" of the line and line itself. Probably solved through use of the "property delegate", but this is new to me and I haven't taken the time to understand this code fully yet.

Reply

• Jan 2, 2019 - 02:15

So, I think I can fix it, but... it seems we support the ability to have some segments of a single spanner above, others below, and this messes up the automatic determination of placement on import, as the placement property is global to the whole spanner. So this whole clever scheme we have where spanners that have been manually adjusted to the opposite side of the staff get marked with an appropriate placement, we can really only do that if all segments are on the same side of the staff. It might make sense to only enable this placement for spanners of a single segment. But in any case, we can't have different segments with different placements - at least, that doesn't work currently.

Reply

Fix version
3.0.1