CRASH resulting from repeat text not being exactly linked with Parts.
- My_First_Score
- add "D.C." to a measure
- File->Parts->"New All"
- in part, double click the "D.C." and change text.
- in part, unselect the "D.C.", reselect the "D.C.", and press Delete. (Observe that the changed text reverts, so you will see a regular "D.C." after the deleted)
- in main score, press undo twice.
crash.
I believe this has a similar cause to https://musescore.org/en/node/105226
I think that the solution relies in having the repeats text in parts be exactly linked to the main score repeat text, such that the main score is the one real version, while all the parts only see a linked version of that main score version.
tested on windows 8.1 x86-64 2.0.3 release.
Comments
I was also going to say that I could produce a similar crash with similar sequences of instructions, even without using the undo operation. So I don't think the undo is essential to this crash. Rather I think the source of the crash is the non-exact linking.
You mean it is related to [#105226], right?
Edit: why is that not turning into a link automagically?
Ah, I see, that is not an issue but a forum topic...
Correct.
(Sometimes I only make a forum post, and not an issue, if I'm not sure I can convince other people something is a bug)
I'm saying both of my complaints could be resolved by having a strict linking between the repeat text elements in parts and main score.
agreed. This is not a layout thing, which is separate between score and part
But I guess this is a duplicate of #64641: Modfying the jump targets of jumps like D.S. are not linked between score and part, at least it is related
Thanks JoJo. Not exactly a duplicate. But same underlying cause, so I believe the correct PR will fix both issues.
My forum post also says in addition to the Jump targets, the actual displayed text is not always properly updated between parts & main score.
Debatable whether the text should sync between score and part, the jump marks definitly should
Well the text should should be global just like the jump markers.
A user might decide to change one type of repeat (e.g. from "D.C.") into another type (e.g. "D.C. al Coda") and just do it by editing the text. Since repeats are something that are global across parts. Same reason that changing a repeat barline should be global across parts.
You may want to have a "To Coda" in the score and a "zur Coda" (same thing in German) in the part? Main issue is that the logic is in sync, the jumps and jump targets
While I could possibly see a desire to have different text in the score versus parts, that's equally true for all text. And also equally true that it would be extremely rare, so while it should be *possible*, it shouldn't be the default. Right now, you can get that by having two separate texts and making one invisible in the score and the other invisible in the part. Ultimately a way to break links would be nice so you *could* choose to have different text. But for now, I would expect the behavior to be the same as for any other text. And for me, this is already the case, at least normally.
I agree the crash here might be due to not being linked correctly, but are you *sure* you can reproduce without Undo? Can you post steps?
marc, I believe I had produced a crash initially without undo...but I am not 100% sure. Then when trying to reproduce I couldn't figure out the exact steps, but then I stumbled upon the sequence I've posted in the description.
Regarding a desire to have different text in score versus parts, I agree with marc that shouldn't be the default. I think like marc says if user wants to have different texts, then should do that with a different text element using visible/unvisible as marc describes.
To be clear, I'd say *for now* the duplciate text visible / invisible is the way to go. Eventually, I fully support the ability to break links, although if you break the link for the text, I'd expect that apply to the playback semantics as well.
I also wonder if this might only be reproducible with mmrests, because it forces a third linked element. So far I can't reproduce this in a situation without mmrests - that is, the measure to which you attach the DC has to end up being part of an mmrest in the part. And as such, I suspect the cause will relate to the way the link / unlink code deals with the undo stack. This code got a bit of an overhaul shortly before 2.0.3, but the crash occurs in 2.0.2 as well, so at least this isn't a regression.
I agree.
(I was also thinking crash might have something to do with mmrests...although I didn't get around to checking the case without mmrests.)
Bumped to critical because of crash.
Interesting insight, Marc. The incorrect handling of mmrests seems to play a key role (the D.C., when deleted, reappears with the original style. This doesn't happen without mmrests).
While testing, I have come across a similar/simpler crash:
nightly a65f06b
1. New score, treble
2. add D.C. to some measure.
3. File->Parts->"New All"
4. delete D.C. in part (notice D.C. stays there)
5. undo
Result: Crash
Seems D.C. also has to be part of a mmrest for this crash.
Famous last words:
Fatal: Element::setProperty: unknown <>(64), data <D.C.> (...\MuseScore\libmscore\element.cpp:1510, virtual bool Ms::Element::setProperty(Ms::P_ID, const QVariant&))
No crash occurs on current master.
Automatically closed -- issue fixed for 2 weeks with no activity.