The Main score's Staff Text gets unintentionally duplicated in Parts (under certain circumstances)

• Aug 3, 2022 - 01:43

After generating Parts for a score I often find that the addition of a Staff Text object to the main score results in two Staff Text objects appearing in the Part. (Note that I'm referring to a players Part when I spell Part with a capital P.

I've tried several times to replicate this from scratch but failed. (See the paragraph denoted with a bullet for general steps that I believe should trigger the behavior.)

Once this situation exists I can click either Staff Text objects in the Part and it appears to select independently. So I thought I could simply select one, delete it, and get on with my work. But on delete, MuseScore deletes both Staff Text objects from the Part, along with the original Text Object in the Score! And the same behavior occurs no matter which "duplicate" I delete.

  • Today I encountered the situation again in a score with linked tablature. So I thought the tablature might be the trigger. So I created a score with linked tablature and generated Parts ... but didn't see any duplicate Text Objects in the Part. So it looked like another failure to replicate the bug ... but later I closed and reopened the score. And voila, on reopening I saw duplicate Staff Text objects in the Part.

The steps to replicate should be something like:

   • New score, with 2 or 3 staves
   • Add some notes in each part in the main score
   • Add a Staff Text to each part in the main score
   • Then add linked tablature to each staff (NOTE: I didn't test with unlinked tablature)
   • Generate players Parts via File>Parts>All Parts

Examine the Parts: Everything looks normal at this point (if you have the same experience as me.)

Then:

   • Close the score
   • Reopen it
   • Look at each Part. They still look as expected ... without any duplicate Staff Text objects.

Here's where the fireworks start:

   • Add a new Chord Symbol or Staff Text object to the Parts.
   • Now look at each Part.
   • For each added Staff Text object or Chord Symbol in the main score we see two corresponding "instances" in the Parts. Doesn't matter whether the object is newly created or pasted.

So perhaps there's some conflagration of Parts, Tablature and Close/Reopen that triggers this. As stated previously, I only tested with linked tablature.

Can anyone reproduce the issue with the steps I've given?

Can anyone devise a simpler replication scenario?

I know there's been a lot of work on Parts in MuseScore 4, so hopefully this bug has been noticed and already fixed.

#334084: The Main score's Staff Text gets unintentionally duplicated in Parts (under certain circumstances)

Scorster

The Ukulele Part shows the duplicated Staff Text object:

Part paste test (with Tablature).mscz

Part paste test.mscz


Comments

I just bumped into a familiar and very similar issue with chord symbols duplicated in Parts.

Starting with a score that has linked tablature and Parts, I deleted a chord symbol in the main score, and then added a new chord symbol in its place.

Result: In the Staff 1 part there's now two "instances" of the chord symbol, one atop the other. As described in the prior post, I can select the upper or lower symbol individually, but deleting one deletes both symbols in the Part ... AND the chord symbol in the main score.

Scorster

The Mandolin 1 Part shows the duplicate chord symbol:

Part with Duplicate chord symbol - Ash Grove.mscz

Having seen no comments to this post over the last couple of days:

a) I'm wondering if anyone can the issue (on opening and examining the attached scores)
b) if my description is lacking or confusing (on terms of the issue and steps to replicate)
c) if anyone has been able to replicate with the provided steps
d) if simply if no one has tried to replicate (or if those able to replicate have not reported to confirm

In reply to by Jojo-Schmitz

Jojo wrote> Last couple days? Last day to be exact ..

Sorry. I’ve been mulling this for a few days and apparently that clouded my grasp of the time since I posted. And I wanted to be sure follow up on this elusive issue and knew that an active discussion would assist in that regard.

I see the problem as significant because I’ve only been able to remedy by deleting the Part—and I certainly don’t want to do after customizing its layout and other details.

Jojo wrote> Anyway: no, i haven't had that issue so far

Good to know …

Were you able to see the issue in either of the attached scores?

Were you able to trigger the behavior from scratch with the steps provided?

Thanks!

scorster

In reply to by scorster

Can you post really precise steps to reproduce the issue? Ive created literally thousands of scores doing something more or less similar to your steps and not encountered problems. So I doubt randomly experimenting with those steps is going to change that experience. But fi you give me completely objective step-by-step instructions to follow, I'm happy to try.

In reply to by Marc Sabatella

Hi Mark,

I thought the steps I provided would suffice. But I can look at fully documenting the issue.

But first I'd like to know how much common ground we have here.

Are you able to see the issue, as described, in both of the scores I attached? If I know that you can I'll be more motivated to make the effort.

scorster

In reply to by scorster

I see duplicate text in the Ukulele part of the "with Tablature" score, yes. But I've never seen behavior like that before, and I don't recall any previous reports of this. Creating a linked part from an instrument itself has linked staves is tricky business, so it wouldn't surprise me if there was some very specific sequence of operations that could reproduce the problem reliably, and this sequence is just uncommon enough that noone else has encountered it yet. FWIW, multimeasure rests also produce a situation where there are additional links - because text attached to the multimeasure rest is linked to a duplicate text on the underlying measure. So, if there is a case where linked tab staves leads to this issue, I'd guess the same might be reproducible for a score that for whatever reason has multimeasure rests enabled (very uncommon; those would normally only be in parts).

In reply to by Marc Sabatella

Marc wrote >> I see duplicate text in the ukulele Part of the "with Tablature" score, yes. But I've never seen behavior like that before, and I don't recall any previous reports of this.

Good. Thanks fo confirming that you see the unwanted duplicate text object in the ukulele Part of the attached "with Tablature" score.

Before I proceed, can you also confirm that:

you can select either of the "duplicates" independently? Said differently, on clicking either of the Text Object duplicates in the ukulele Ppart, the clicked on highlights.

• with one duplicate selected/highlighed, on delete, both both duplicates disappear from the Part, and the linked text in the main score is also deleted?

pasting a Staff Text object to the ukulele staff (in the main) score always results duplicates in the Ukulele Part?

adding a new Staff Text object to the ukulele staff (in the main) score always results duplicates in the Ukulele Part?

Adding a Chord Symbol to the ukulele staff (in the main) score always results duplicates in the Ukulele Part?

In reply to by Marc Sabatella

Mark wrote >> Once the score is corrupt tons of bad things can happen

Sure.

Mark wrote >> ... so it's not very interesting to look any further and talk about which symptoms one person sees versus another.

Okay. No one seems interested in verifying if they see the same behavior that I'm encountering. As you know, I was hoping for verification (and to have the information documented here) before making further attempts at specifying exact steps to replicate.

Until such a time I'll abandon the effort ...

In the meantime I'll post a link to this discussion in the Issue Tracker

Over and out.

In reply to by scorster

Indeed, to be clear: no one is interested in exploring all the possible bad things that happen once a score is corrupted. That provides zero value so it’s wasted effort. We want all effort focused on how the score got corrupted on the first place. That is the one and only thing that will help get the problem resolved - being able to reproduce it from scratch. It’s important to focus on effort on where the value is. So don’t abandon the valuable effort - on the contrary, that’s where I want you to focus.

In reply to by Marc Sabatella

marc wrote>> Indeed, to be clear: no one is interested in exploring all the possible bad things that happen once a score is corrupted.

No one here is asking for an exploration of "all the possible bad things that happen once a score is corrupted."

marc wrote>> That provides zero value so it’s wasted effort. We want all effort focused on how the score got corrupted on the first place. That is the one and only thing that will help get the problem resolved - being able to reproduce it from scratch. It’s important to focus on effort on where the value is.

None of this is lost on me.

marc wrote>> So don’t abandon the valuable effort - on the contrary, that’s where I want you to focus.

Considering it could require another hour of my time to fully document steps to replicate, and since it seems no one has tried the steps I've already described—and that it would take about 30 seconds for someone to answer my inquiry—I'll wait.

I don't get it Marc. It would have taken less time to answer my question than write your rebuttal on why you don't want to. Ironic that the thesis of your rebuttal is about saving time and effort.

I don't care who answers the simple questions I posed, but I'll wait until someone does.

scorster

In reply to by scorster

You have to understand I spend hours a day volunteering my time helping people here. I am passionate about helping people here, and equally passionate about helping make MuseScore the best it can be, for the benefit of all of us. When I see a bug report that seems serious but lacks precise steps to reproduce, I am passionate about helping the person who reported it find those steps. Helping people submit good bug reports is absolutely worth my time, because it will result in the improvement of MuseScore for all of us.

But, my time is limited, so I need to direct it towards things that will actually help. I applaud your interest in seeing MuseScore become better. We share that interest. I simply want to see your energy directed in a way that will actually help achieve that goal. Helping you get to the bottom of this is a valuable use of my limited time. But I don't see the value - to you, to me, to MuseScore, or to other users - of spending time on an already corrupted score to see what happens if I do A, C, or C. Helping you reproduce the problem and thus submit a good bug report has great value - to you, to me, to MuseScore, and to all users. So I'm willing to spend some of my limited time on that.

So, bottom line: please understand my time is limited, I try to spend it only on things that have value. helping you produce a good bug report is valuable. The time I spent on this post is valuable if it helps you focus your effort on producing that good bug report.

In reply to by Marc Sabatella

Marc wrote >> FWIW, multimeasure rests [in the main score] also produce a situation where there are additional links - because text attached to the multimeasure rest is linked to a duplicate text on the underlying measure [in the Part]. So, if there is a case where linked tab staves leads to this issue, I'd guess the same might be reproducible for a score that has multimeasure rests enabled [in the main score.]

I think your sentences implied what I made explicit by adding the bracketed text. Did I get it right? If not, please help me out.

Anyway, this is an interesting point because Parts have multi-measure rests enabled by default. Correct?

scorster

In reply to by scorster

All multimeasure rests create links, but it's ones that exist in the score that potentially cause problems, because it's code that is very untested given that it almost never happens in real life. Same with generating parts from score that include linked tablature - not as uncommon, but certainly, not the vast majority of scores with generated parts don't include linked tablature, so again, it's code that is less well tested.

The fact that parts have multimeasure rests generated by default isn't particularly significant. The potential problem is when links already exist nbefore parts are generated. This is the unusual and less tested case that you are running into, and that I am hypothesizing people who enable multimeasure rests in scores might run into - generating parts where links already exist could potentially cause problems under the "right" circumstances, because that code gets tested very little and who knows what might go wrong.

The only inserted text of yours that is wrong is "in the part". My whole point here is that multimeasure rests involve links completely independent of whether parts exist. Text attached to multimeasure rests is duplicated, deliberately, between the multimeasure rest and the normal underlying rest, so if you change the text then disable the multimeasure rests, you see the change in the text on the underlying measure.

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