[MU4 Issue] Notes missing from staff 5 on musicxml import

[looptailG]

Describe the bug
The notes in the fifth staff of an instrument are not imported correctly on musicxml import, and are instead replaced by invisible whole note rests.

To Reproduce
Steps to reproduce the behavior:

1. Create a new file with an instrument, and add staves to it until it have 5 staves.
2. Add a few notes to each staff.
3. Export the file to the .musicxml format. If you open the .musicxml file with a text editor, you can see that the information about the notes in the fifth staff is present.
4. Open the .musicxml file with Musescore.

Every measure of the fifth staff in the opened .musicxml file is filled with an invisible whole note rest.

Expected behavior
In the opened file the notes of the fifth staff should be the same as those of the original Musescore file.

Screenshots
Original Musescore file:

Imported .musicxml file:

Platform information

• OS: Windows 10
• Musescore version: 4.0.1-230121751

Additional context
The same issue happens if the file is imported with Musescore version 3.6.2.548021803.

[Jojo-Schmitz]

Sample files in https://musescore.org/en/node/345637

@lvinken ?

[lvinken]

The issue also reproduces using simple one measure five staff part. Will have to search for the cause, it does not immediately looks familiar.
Update: issue seems related to the voice mapping algorithm: it seems to use Ms::MAX_STAVES (which is 4 in 3.6.2) as the maximum number of staves per part. See NoteList::anyStaffOverlaps().

[lvinken]

Further investigation shows that the current MusicXML importer contains two kinds of MAX_STAVES sized data structures: the voice mapping data and the per staff octave state. It also seems that in the current MuseScore releases (both 3.x and 4.x) MAX_STAVES is used for the maximum number of staves in an instrument template only. It obviously does not limit the actual number of staves in a part.

The structural solution would be to make these MusicXML importer data structures dynamically sized. A crude solution is to create a local fixed (larger) size. Attached zip file (issue_16543_simple_example_and_trivial_3.6.2_fix.zip) contains an experimental 3.6.2 version of the last one.

[Jojo-Schmitz]

I can confirm that this fix does help in the OP's case, but not with your sample score of 10 staves. Which isn't much of a surprise, as your fix increased the number of staves from 4 to just 6, not 10. But maybe 6 (staves per part) is just enough un general.
Anyway, I've now integrated it into my PR #9000

[lvinken]

Hi Jojo, the 10 staff example was meant to illustrate that the changed constant indeed affects the number of staves imported. Wrt the solution, not knowing how many staves could be present, I consider any fixed maximum number a needless limitation. Six is indeed just a random choice and not a recommendation, feel free to increase the value. I still prefer dynamic sizing, but did not have the time to implement that.

[Jojo-Schmitz]

Understood. Not sure this corner case (of a part with more than 4 or 6 or whatever staves) is worth any big effort