If scores containing pre-generated parts are joined using Album, then each part of joined score only contains 1st score.

Alternative workaround: open the joined mscz, delete all parts, and then regenerate all parts. Then each part will display all movements. (Unfortunately if the user had made any part-specific modifications such as spacing, then those changes will be lost upon deleting parts.)

I suspect the problem is with how scores are appended when creating an album. I suspect that only root scores (without their child parts) are appended. That would explain why only the first score is displayed in each part of the joined score.

I notice Album::append (which is called by AlbumManager::addClicked() and Album::load) only appends one score. I think the solution is to have Album::append iterate over all child scores and append each child score to the corresponding child of the joined score, in addition to joining the root score. I think I can fix this easily with a couple lines for iterating over child scores and checking that the corresponding child scores exist before appending child scores. Can I be assigned this?

Caveat: to handle the case where generated parts only exist for some (but not all) scores in the list, I think that before appending the scores, it is necessary to generate a list of what parts have been generated, and then at the time of appending the scores, Album::append should iterate over this list and generate child parts for all root scores that do not already have a generated part for a score. That way, the joined score will not loose any part specific edits that were made before joining.

CRASH occurs after performing replication steps if try to add a note in the 2nd (or later) movement. This is because the child scores do not even contain those measures past the 1st movement. This increases the seriousness of the bug.

Can I assign this bug to myself and submit pull request based on my suggested fix?

OK. I don't want to delete the parts, because in my use case I would probably have painstakenly inserted line & page breaks in the indiviual parts first and wouldn't want to loose them.

Anticipating some compilcations...thinking out loud: Part object is composed of a list of instruments, and any *combination* of instruments can constitute a part. So in addition to considering that each movement may contain a different set of parts, there could be situations where the part lists are mutually incompatible.

Feature request #40251: joining scores via album requires all scores to have the same number of parts and staves would make this fix easier, but I don't want to make that assumption, because real compositions/books may have a different set of instruments in each movement/section. I think upon joining such movements together, the expected behavoir should be that musicians who are left out of movements should have a bunch of rests in their part.

Now the simplest solution is have the album code delete all parts first before joining together. As I said in previous comment, I don't want to loose part specific edits.

Next simplest solution would be to treat the part list of the first movement to be the authoritative answer to what will be the part list of the joined score, such that:

• Subsequent movements with parts not named by an exactly matching partName string in the first movement will first have those parts ignored (so any part-specific edits will not be copied to the joined score).
• Subsequent movements with part names exactly matching original will have those parts be appended to corresponding child score.
• Subsequent movements lacking parts named in the first movement will have new parts be automatically generated and appended to corresponding child score. For each partname in original score:
• if subsequent movement contains instrument(s) matching that partname, then the child part will be generated from those instrument(s).
• if no matching instrument(s) exists, just generate an staff of that instrument(s) filled with empty measures.

I'm going to go this route because it is much easier than figuring out what the "merged" part list is given an possibly random arbitrary set of parts.

(I've noticed that musescore 2.0.2 will let me append a Soprano Solo mscz to a SATB mscz, and will let me append a Piano mscz to a SATB (although converting the piano into S & A), but will not let me append a SATB mscz to a Soprano Solo mscz. So I'm just noting that musescore currently permits subsequent scores with a smaller or equal number of staves to be appended without complaining, but not the reverse, regardless of the status of feature request #40251: joining scores via album requires all scores to have the same number of parts and staves.)

I've fixed this specifc bug and submitted a pull request https://github.com/musescore/MuseScore/pull/2138. As I was doing the fix, I gave up on attempting to implement all that I said the above comment. I think anything more than the necessary fix would be better written as a seperate feature request. I am assuming identical parts in each score (with identical ordering of parts). I am only testing to make sure that there are an equal number of parts in each score and am testing that each part actually exists before trying to append, or else I display a meaningful qDebug message. I don't think I have changed any behavior for scores that lack pre-generated parts.

I changed status to "patch (code needs review)" because I think that indicates that I want someone to look at the pull request and approve it or give me feedback.

I've tried out the windows nightly build e2bbe3f that has incorporated my pull request, and it seems to be working. I've tried joining multiple scores with excerpts of identical ordering of excerpts and the joined mscz has all movements in all excerpts, and I'm able to add notes without crashing. And trying to join two incompatible scores of different amount of excerpts is refusing to do so and popping up an error, instead of trying to merge them. So I'm marking this specific bug as fixed.