Edits to system text/tempo marking after save and reload of score do not propagate to all parts.
Reported version
3.5
Priority
P0 - Critical
Type
Functional
Frequency
Few
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
Yes
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.1.293615790, revision: 12ab1d9
Create a score with two or more instruments
In first bar Add>Text>System text/tempo marking
Create all parts
Save and close
Re-open score
Edit System text in score.
Result: edit is propagated to the first part only. It does not show up on other parts. Deleting the text also only affects the first part.
Edits are propagated to all parts if steps 4 and 5 are skipped - i.e. if the score is not saved before making an edit.
@mike320 confirms and reports this is a regression from 3.5.0.
Fix version
3.5.2
Comments
I use the same MuseScore version for Windows.
Can`t reproduce this issue. Could you add more details or add link to a video with reproducing this issue?
I think the step "Create all parts" is not clear for me. Could you clarify how to "create all parts" (for example)?
File > Parts > All parts
In reply to File > Parts > All parts by Jojo-Schmitz
I need clarification to be sure that I understand the issue.
When I am trying to change System text (for all parts) the issue is that this text doesn`t change for single part (when I switch tables to this parts - screenshot added)
If I missed something or wrong , please correct me.
That exactly is the issue. If you change a system text in the (main) score ("all parts" as you call it) it should change in every single part. And vice versa. As this is what a system text should do, along with tempo markings, rehearsal marks, repeats and jumps, and some more.
Thank you. Now I can reproduce this issue
Most likely caused by https://github.com/musescore/MuseScore/pull/6124 to fix #257581: Changes to Measure properties are not propagated between score and existing linked parts after save/reload
and as such indeed a pure and plain 3.5.1 regression
Definitely, we've identified the specific lines involved, where we write the link info for the measures to the score file. What we are not sure about is what to do about it. Removing the lines fixes this problem but presumably leaves the rest of the measure properties code in an inconsistent state.
Fixed by reverting the fix for #257581: Changes to Measure properties are not propagated between score and existing linked parts after save/reload and #64636: "add to measure number" is not linked between score and parts after reload
In reply to (No subject) by Jojo-Schmitz
I just tested this. It seems fixed for a new score created in 3.5.2 but not for a score previously created under 3.5.1.
To reproduce:
result - edits show up in first part only, not in other parts.
Save and re-open after editing has no effect.
Saving the 3.5.1 score from 3.5.2 before editing does not change the behaviour even if saved with a new name and even if other edits are made before saving. It seems that a score saved under 3.5.1 is forever doomed!
In reply to I just tested this. It… by SteveBlower
As there has been some confusion about downloaded versions recently. This is what I am working with:
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.5.2.311459983, revision: 465e7b6
Remove and regenerate the parts
In reply to Remove and regenerate the… by Jojo-Schmitz
If (as in my case) the parts have been significantly tweaked to optimise layout, the least bad option is to add a new system text and then delete the old ones in the individual parts (in my case that is 23 parts x 3 tempo markings per part = 96 deletes).
That is another workaround indeed, just not the savest, as you may miss some
Unfortunately the bug was such that the error was on writing the file, so once corrupted, it isn't easy to fix. And actually, merely deleting the texts doesn't completely fix the underlying problem, just the symptom - there are most likely other ill effect of the bug unfortunately, even if I can't say for sure what exactly they might be. Other elements not linked properly, basically. So really, deleting and regenerating the parts in any "infected" score is probably best.
However, simply saving the file in 3.5.2 does cure the underlying problem, even if it doesn't eliminate the symptoms that already manifested. So if you can't bring yourself to delete and regenerate the parts for a score already saved in 3.5.1, I would suggest first opening and saving in 3.5.2, then closing and reopening, before you begin the cleanup process. That should maximize chance of success.
BTW, instead of deleting the tempo texts one by one in the parts, you could at least use Select / All Similar Elements.
In reply to Unfortunately the bug was… by Marc Sabatella
Fortunately, I only used 3.5.1 to doom this one score. Yes, I should have used select all similar, but in the heat of battle one forgets. Anyway, the score is fixed and 3.5.2 was turned out much sooner than I could have hoped and seems to be working well.
Automatically closed -- issue fixed for 2 weeks with no activity.