Extensive corruption quagmire due to Linked Tablature and generated Players Parts

• Aug 7, 2022 - 22:59

I've recently reported that corruption consistently occurs when I generate players Parts in scores containing linked tablature.

    [ Example score attached below ]

After generating players Parts in a score with linked tablature, corruption is set to occur (or has already occurred) whenever I add various objects to the main score. Provocative objects include Staff Text, Chord Symbols, Chord Diagrams ...

Each provocative object added to the main displays as a pair such objects in the relevant Part ... BUT ONLY once I've reopened the score after generating Parts! Thereafter any provocative objects added to the main score immediately show in any existing players Parts—and are usually displayed at a slightly different elevations due to slightly different y coordinates (not due to "automatic placement".)

I have lots such scores (linked tablature with generated Parts) that are not yet corrupted but will become corrupted if I add a provocative symbol—and there's no indication of trouble afoot until I close and reopen the score. So I have to step carefully and mindfully, wary that a single lapse of attention (i.e. the addition of a main score object) could corrupt the score.

• Sometimes the corruption is unreported on reopen, although detectably visible in the Parts, as described. I had hoped that deleting the players Parts would clear the corruption, but as far as I can tell, it does NOT. After deleting all players Parts and generating them anew I see the duplicates of Staff Text and Chord Symbols added after generating Parts.

Suggestions?

Sometimes MuseScore posts a corruption report on opening the score. But fixing is not straight forward (actually not attainable) because the corruption report does not match the situation in the score. For instance, the reports says, "Staff x incomplete. Expected: 4/4; Found 14/8." BUT the specified measure IS already set to 4/4. Previously on seeing such a report I go to measure x open Measure Properties and reset the values to 4/4, or grapple with other tenable issues. Ironically, playback sounds like perfect 4/4. I'm clear that corrupted scores could behave erratically and not as expected.

NOTE 01: It's unclear if the "metrical corruption" occurred due to the Linked Tablature/Parts issue or if there was some other cause.

NOTE 02: After deleting the Parts of the attached score, saving and reopening, I see the same corruption report window. So I looked at the score in uncompressed mscx format. The score consists entirely of nominal 4/4 with occasional pickups. I didn't see any 14/8 or other errant meters mentioned in the Alert. But I did see lots "LinkedMain" xml tags. This is of interest because I don't think those tags exist in regular "Partless" scores. Right? I'd think that are such "link" artifacts would be purged on deleting all Parts (at least from an uncorrupted score.)

Any advice on moving forward without losing five hours of work creating the score?

Previously I've been able to easily fix corruption in a number of ways, for instance:

• delete the corrupted measure and "rebuild" it (often by first copying the contents and pasting into a new measure. Pretty easy!)
• check Measure Properties and correct the value in Nominal or Actual

But in the attached score MuseScore states Measure 41 is corrupted ... but when I delete it and add a measure, on reopen, MuseScore reports that the new Measure 41 is corrupt, with meter 14/8. It's like a bad penny.

My larger concern is that this is just one of probably hundreds of my scores in jeopardy.

I hope someone can help find a way to decorrupt such scores.

Ideally the issue is already fixed in MuseScore 4 and that it will be able to purge the corruption from such scores on open.

scorster

The attached score Steel Rail Boogie is an original composition for teaching hammer-ons, boogie accompaniment and improvisation:

   • Page 1 has simple melody with a recurring hammer-on phrase.
   • Page 2 shows an effective approach to learning hammer-ons.
   • Page 3 shows two simple scales for improv
   • Page 4 illustrates a "Johnny B. Goode" style solo

   • Pages 1 and 4 are set to repeat multiple times as students practice hammer-ons or improv.
   • The boogie accompaniment is in a Part hidden in the main score.

Playback sounds completely normal even though MuseScore reports metric corruption on Open.

     Steel Rail Boogie Melody and Accomp GTb.mscz

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