Text attached to mmrest preceded by another mmrest ending with custom barlines loses custom position on reload
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Randomly
Status
closed
Regression
Yes
Workaround
No
Project
- Create a score
- Add text elements (rehearsal marks, staff text, etc.)
- Change the offset of these elements
- Save, close, and re-open the score
- 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 |
Fix version
3.4.0
Comments
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.
Here is the score.
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..
I should mention, I can reproduce on this score but can't seem to figure out a way to reproduce it from scratch.
In reply to (No subject) by Marc Sabatella
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.
As I said, I cannot reproduce. Can you give precise step by step instructions?
In reply to As I said, I cannot… by Marc Sabatella
It appears that text will not reset its position on a mmrest on the first system, but will reset on mmrests on subsequent systems.
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.
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.
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.
Indeed for August 30.
- This nightly works: f38f58e
- Text attached loses their custom position with this one: 5b02dc0
(and so this commit https://github.com/musescore/MuseScore/pull/4846 is between them)
See https://github.com/musescore/MuseScore/pull/5451
@Marc Sabatella, thanks for your investigation! The issue is indeed in linking elements and actually includes two issues with linked elements: one is about writing linked bar lines in MM rests, another one concerns reading or linked elements. Both should be fixed with that PR.
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._
Fixed in branch master, commit 8f107f34dc
_Merge pull request #5451 from dmitrio95/296426-mmrest-barline-text-links
fix #296426: fix not linking multiple elements at the same tick in MM rests on score loading_
Automatically closed -- issue fixed for 2 weeks with no activity.