Text attached to mmrest preceded by another mmrest ending with custom barlines loses custom position on reload

• Nov 1, 2019 - 17:46
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Randomly
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore
  1. Create a score
  2. Add text elements (rehearsal marks, staff text, etc.)
  3. Change the offset of these elements
  4. Save, close, and re-open the score
  5. Some of the elements will have reset to their original positions

In the attached image, all of the rehearsal marks and measure number ranges are supposed to look like line "A". This worked fine in 3.2, seems to be a 3.3 issue.

Attachment Size
Text Element Bug.png 165 KB

Comments

• Nov 1, 2019 - 20:11
Status active ⇒ needs info

In order to investigate, we need the actual score, not just a picture. Whatever the trigger is, it likely has to do with specific settings.

Reply

• Nov 1, 2019 - 20:50
Severity S4 - Minor ⇒ S2 - Critical
Status needs info ⇒ active
Type Graphical (UI) ⇒ Functional

I can reproduce. Seems to relate specifically to markings at the start of multimeasure rests, perhasps also only at start of system and/or in conjunction with a key change. They are being duplicated as well - presumably one copy on the mmrest, one one the "real" rest underneath.

My guess is this actually was an issue on 3.2.3 as well but again, only in this very specific set of situations, or perhaps a slightly different set..

Reply

• Nov 1, 2019 - 21:01
Title Text Elements reset to original positions after closing and opening a score ⇒ Text Elements attached to mmrests may lose custom position on reload

I should mention, I can reproduce on this score but can't seem to figure out a way to reproduce it from scratch.

Reply

• Nov 1, 2019 - 21:40

I tried recreating on a new score. The rehearsal marks are now staying in place, but it seems that any other text at the beginning of a multi-measure rest (except for ones that break the mmrest) will reset to original position and leave a duplicate at the new position. If I try to delete the reset text, the duplicate text will also be removed.

Reply

• Nov 1, 2019 - 22:18
  1. Create new score (I tested with both one and multiple instruments)
  2. Create multiple systems and place a double barline at the end of each.
  3. Press "M" to bring up multi-measure rests
  4. Click on each mmrest and add text
  5. Move the texts (I've tried using keyboard arrows, adjusting X and Y in the Inspector, and dragging with the mouse)
  6. Save and close score
  7. Re-open score

It appears that text will not reset its position on a mmrest on the first system, but will reset on mmrests on subsequent systems.

Reply

• Nov 2, 2019 - 15:56

Confirmed. There seems to be something else to it besides first vs subsequent systems because I swear I did try that and it worked at first, but those steps do indeed fail.

Reply

• Nov 2, 2019 - 18:27

After some more investigation, it seems the necessary conditions to trigger the problem are this:

1) the text needs to be on an mmrest
2) there needs to be an mmrest immediately before this mmrest as well
3) the two rests need to be separated by a double (or other custom) barline

System breaks turn out not to be involved, but of course, you can't reproduce these conditions on the first measure, because it won't be preceded by an mmrest (it's not preceeded by anything).

If the conditions above hold: mmrest, double bar, mmrest with text - then the text won't be "linked" properly, leading to the prlblem at hand and possibly others as well. The underlying problem most likely the change I made regarding text and mmrests in https://github.com/musescore/MuseScore/pull/4846 - the link probably has not been established correctly since 3.1 at least (when I also made some fixes to barlines and mmrests) but this didn't cause this particular symptom until the more recent change.

It's possible, then, that I broke something with my changes for barlines at 3.1, but it's also possible things were broken before that in ways that just never happened to be noticed. The key has to do with the use of the indexDiff tag on the text, which is being written for the text but seems to not be hooking up properly on read, causing it not to be linked properly, which in turn causes the loss of the offset info.

Reply

• Nov 2, 2019 - 18:30
Title Text Elements attached to mmrests may lose custom position on reload ⇒ Text attached to mmrest preceded by another mmrest ending with custom barlines loses custom position on reload
Priority ⇒ P1 - High

Title changed to reflect what I see to be the most accurate statement of the issue. The loss of info makes it "critical" according to our usual definition.

Reply

• Dec 5, 2019 - 12:34
Status PR created ⇒ fixed

Fixed in branch master, commit 907a4dcc31

_fix #296426: fix not linking multiple elements at the same tick in MM rests on score loading

The issue has two parts:

1) If a linked element belongs not to the first MM rest measure (e.g.
a BarLine), and tags may have been written out
of a proper order.
2) If several links bind pairs of elements in the same score at the
same tick, these linkes may have been not established properly on
score loading.

Both issues needs to be fixed to fix linking of elements in the case
described in the issue (MM rests split by a barline with text elements
attached), so both fixes are included to this commit._

Reply

Fix version
3.4.0