chordnames not propagated to parts if parts generated after score load

• Oct 11, 2013 - 17:54
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Windows 7, GIT commit: 3e51505

I find that "sometimes", upon generating parts from a score containing chordnames, the chordnames are not propagated in the parts. I've been trying to figure out what triggers this, and *may* have found the answer:

1) open attached score
2) file / parts
3) new all
4) OK
5) view flute part

Result: the chordname is not present, but the staff text is

I can reproduce this every time using this score, which is nothing more than a few notes and chords. However, if I re-create this score from scratch and generate the parts immediately - no loading of score from file involved - the chordnames are propagate correctly.

So it seems that in some way, the way chordnames are represented in the score upon initial entry differs from how they are represented after a load of a score in terms of how they are handled by the part generation. Now, I guess I know as much as if not more than anyone about how chordnames are represented in a score, and I can see how there would be subtle differences here. I'd have to step through in the debugger to remind myself of specifics, but I know what I'd be looking for.

However, I know *nothing* about how the linked part facility works, so I wouldn't know whether I really need to change anything about the chordname representation or if this is just a bug in the linked parts facility.

I kind of suspect the latter, and that it might relate to #18507: some text items modified in score after generation of linked parts not reflected in those parts.

Attachment Size
linked_text.mscz 1.73 KB

Comments

• Oct 11, 2013 - 19:26

Additional info: if you save the score after the final step, then close and reload, the chords are present. However, you can then induce a crash using the following steps:

1) view flute part
2) double click the C7 chord in measure 1
3) hit tab three times

As soon as the chord entry cursor moves to the multimeasure rest, MuseScore crashes. This whole series of steps is reproducible in any score. That is, tabbing from a chord symbol into a multimeasure rest doesn't *always* crash, but I think it always does if this same basic sequence is followed in terms of the order in which you do things: generate the chords, save/reload, generate parts, save/reload, then edit & tab into multimeasure rest.

Reply

• Oct 11, 2013 - 23:03
Status (old) fixed ⇒ active

Latest changes fix the non-display issue, but the crash remains. Follow the steps as given in the original post and the followup #1: load score, generate parts (this much now works correctly), then save, then reload, then edit a chord in the part and tab into the mm rest.

I was able to do a little investigation.

The crash happens because in Harmony::layout, line 835, Measure* m is set to parent()->parent(), but this is 0, and then it's being dereferenced. I guess it's supposed to point into the parent score.

If you skip the save/reload, this works. Immediately after generating parts, view the flute, double click the chord, tab three times, and the cursor moves into the rest as I guess I should expect (not really sure what I expect, but that's another story). parent()->parent() is returning a valid measure object, presumably in the parent score.

Reply