MS 4.2 still dropping text lines from parts

• Jan 9, 2024 - 13:21

This has been reported before but I found that it still does at least text items from score to part. Ihave known one place but found another at bar 1 where three out of six parts were missing rallentando text line. When I checked they were missing from earlier pdf prints as well. They can be returned just by cut and paste but they dissappear again when re-opening the score. I did a test resetting one part (which also returns the txt lines) but after paging it again the same parts miss the lines again after re-opening.
One possibility is that it can not cope with system level lines with anchoring different than that on the part in question. But surely there can't be that kind of problem any more?
I attach a print from score and on part where this has happened.

Attachment Size
part_problem.jpg 174.58 KB

Comments

I did a quick test with 10 first bars copying to an empty score and creating just that one part. Result was the same. After creating the part text rallentando was on the part but after just closing and re-opening the score the text was gone on the violin II part.

Attachment Size
testi_parts.mscz 46.95 KB

It's been reported a few times but so far no one has found steps to reproduce the issue. As soon as someone does and reports them, it can be fixed.

In reply to by Marc Sabatella

Did I not just describe it? I also descibed what the cause most likely is. Well, in short again:
1) open testi_parts. Violin II is missing rallentando.
2) In parts reset the violin II part. Rallentando re-appears in the part.
3) Save file and close it.
4) Open the file again. Rallentando is missing again in violin II part.

In reply to by jounip

You described the symptom nicely, so indeed we can see the effects of the bug by following your steps. But since the error is already present in this score, it's then too late to investigate the cause. What is needed is a way to reproduce the problem starting from a score that doesn't already exhibit symptoms.

The fact that in your case the symptom reappears even after the reset is unusual, and maybe that extra information will be of use in trying to track this down. So please do ZIp and attach this score to a comment in the GitHub issue dedicated to this - https://github.com/musescore/MuseScore/issues/20086

In reply to by mercuree

Good catch! Yes, Ican see that this is caused by that special case of the line starting at a beat position that simply doesn't exist in one or more parts, because the rhythms don't align. Having the tempo change start mid note is kind of awkward to read anyhow, so consider starting the line a little earlier or later so it matches in all parts. Or rewriting the rhythm of the affected parts so that the start beat has a note associated with it. Or if you want a workaround that doesn't involve visual changes to the score, add invisible rests in another voice. Anything to give the line a valid start position in each part.

In reply to by Marc Sabatella

I already combed through this score and found 5-6 similar places but are they all there is? This is the biggest concern.
I already corrected some instances like you suggested. But not all could be fixed by moving the start. Like a short rallentando line just before bar change.
There is a solution because the lines appear in the part for some time after reset. Probably just not saved on disk.

In reply to by jounip

Actually, I'm guessing they are saved, but are lost on the reload.

Another workaround I found is to add a system text along with the tempo line. Easier and less intrusive than dealing with extra rests and multiple voices. System text has been around a long time so the code is there to make sure they get written and read even when not apparently attached to anything in a part. Gradual tempo change lines are new and that's how this case got missed.

In reply to by jounip

Yes, as noted in the GitHub issue, this problem exists has existed since MU3, or whenever system lines were first introduced. I think probably it didn't get noticed until recently because they weren't commonly used. The problem should fix itself when the new system is implemented to allow lines to start and end anywhere and not require a note/rest to anchor to. But that might still be a couple of updates away, so for now, the system text workaround seems to be the way to go in cases like this.

Do you still have an unanswered question? Please log in first to post your question.