Two piano instruments shown for a single piano part after save/load

• May 19, 2020 - 09:34
Reported version
3.4
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore

1) Create an empty score with e.g. Piccolo and a Piano.
2) Open Parts form (menu -> File -> Parts).
3) Create All parts (using the "All parts" button).

Now tho form look like:
image-1.png

4) Save the score.
5) Close the score.
6) Reopen the score.
7) Open the Parts form (menu -> File -> Parts).
8) Select the Piano part

image-2.png

Now the the piano is shown twice.
Same issue is seen in MuseScore 3.0, 3.3 and 3.4.

Comments

• May 19, 2020 - 15:40

Is that because Piano has 2 staves?

BTW I can confirm this for MuseScore 3.1 and 3.2.3 too.
Not in 2.3.2 though, which might make this a regression?
Might be related to the parts-of-voices feature?

Reply

• May 19, 2020 - 15:52

I think so but that is not a reason to create 2 parts, just one part with two staves.
When you create the part, everything looks fine (see the first image), just after loading the score again the second part comes up. It seems to me an issue in reading the score.
It looks the issue is related to the fact the score is read sequentially and some decisions are made while the context it not clear yet. Is this sense it similar to #297501 Layout shift of slur after reload

Reply

• May 19, 2020 - 17:36

If I'm understanding correctly, there aren't two piano parts - just a single piano part. it just shows up in the dialog as being made of two instruments.

Is this just a dialog display glitch, or does something actually go wrong as a result of this? If the former, I wouldn't call it "major", nor "functional" - it would be minor / graphical. I could imagine things going badly if we allowed further editing of the part definition at this point, but I don't think we do?

Reply

• May 19, 2020 - 17:57

I don't think it is a dialog display glitch, I found while working on that display :-). What puzzles me I see this issue only after reading the score again. While iterating over the parts in the Excerpt, after loading the score, the Part comes up twice with the same staves. This doesn't happen when the parts are created and the display is reopened. Then we see only one single Part. It seems pretty clear the extra Part is created while reading the score.
There are some more issues there, e.g. tracks QMultiMap is created after the scores/parts are read. So all code, relying on the correct tracks map assumes a kind of default map unless a mapping is specified (voice-to-parts). I'm not 100% confident reading parts is correct.

Reply

• May 19, 2020 - 18:24

What I mean by dialog display glitch is, as far as I can tell, nothing actually goes wrong with your score, correct? The only thing it does is cause the dialog to display some incorrect information? Don't get me wrong, it's a bug, I'm glad you found it and have a fix, but I'd still like to understand what is going on. Because if something is actually going wrong with scores after these steps, its showstopper critical and we have a disaster on our hands trying to fix the millions of scores created since 3.0 was released that are impacted by this. I think that's not the case, though - the only symptom that I can if that the dialog displays incorrect information, but in no way impacts anything else. Unless it does, which is what I'm still trying to ascertain.

So if you're saying it is not just a dialog display glitch, please explain the actual thing that goes wrong in terms of how it affects your score or how you work with it.

Reply

• May 19, 2020 - 19:28

So far, I can't tell something goes wrong with the score. Even though the dialog shows two piano parts, you can not edit these parts so the dialog will do nothing with it (because there are no changes for the part so part is not recreated, the track mapping, which is mainly what counts, will not change).
Whether something else goes wrong depends on what methods of Excerpt are used. I don't think the Excerpts::parts() isn't used that often and this where it goes wrong (at least, that's what I see here). The Excerpt API seems somewhat underdeveloped, a lot of retrieval of information relating to excerpts is done when required (resulting in some duplicated code).
For me the issue is major, not because something goes wrong immediately, but I fear it is an accident to happen. It is one thing I have on my list the explore further.

The good news, even when there is really something wrong, I don't think we have a disaster with millions of scores. When looking at the MSCX file, it looks to me all information is there and even in the right order but the reading logic is not correct. That's what I have to dive into further.

Reply

• May 19, 2020 - 19:47

OK, thanks for the update. If you do find a way to make something bad happen, do let us know, because we will need to then understand how to deal with the effects of it. So I'm hoping it turns out to be just an issue with the dialog display and nothing else.

But again, the dialog is not showing two piano parts. It shows a single piano part, that happens to contain two copies of the piano instrument. At least, using the terms the way they are used in the UI. I know that in the code the word "part" is used to mean something very different from what it means to the user.

Reply

• May 19, 2020 - 20:15

The problem is, the dialog does show two piano parts. But they share the same staves. The same Piano Part object appears twice in the _parts list in Excerpt (really same object, same pointer). A quick search shows Excerpt::parts() is used only a few times.
But the main issue is when somebody starts to use the method, sees this issue and think this is the normal behavior (as I did for a while) he/she might create a work-around which might work only on a loaded score, not on a created score. Or it breaks some special voice-to-parts cases (e.g. when somebody uses voice-to-parts to split voice 1 and 2 on two staves in the same excerpt, this is one of my test examples :-)).

Reply

• May 19, 2020 - 20:21
Title Piano is shown twice in Parts form after loading the score. ⇒ Two piano instruments shown for a single piano part after save/load

Again, if we use the word "Part" the way the user interface does, there is very clearly only one piano part here. The parts are shown in the top section of the dialog, and I see one Piccolo part and one Piano piano. The multiple pianos are listed where it says "Instruments in Part", and only when the piano part is selected at top. So very specifically, this is saying that the one and only Piano part has two instruments, both named Piano. The fact that the code calls these instruments "parts" is unfortunate, but in case of conflict as there is here, it is best to keep the issue tracker focused on the user-visible terminology.

Reply

• May 20, 2020 - 07:46

@Jojo-Schmitz The PR doesn't solve this issue but the selection of the second part. As a matter of fact, the second, wrong, part has no voice selected.
image-3.png
But there is still a second piano part which shouldn't be there.

Reply

• May 21, 2020 - 18:43

Root cause is found. When reading a score, MasterScore::addExcerpt() is called and this method iterates over the staves and creates a Part object for every staff. That's why the piano appears twice in the Instruments in Part list.
This cause only problems when iterating over the parts of an excerpt, the results differ whether excerpts are created or were in the loaded score already.

A small check on how often this Excerpts::parts() us used shows it is not used that often (yet?). Except in excerpt.cpp and excerptdialog.cpp, the method isused in file.cpp (MuseScore::getNewFile()) and unrollrepeat.cpp (MasterScore::unrollRepeats(). But when a score contains excerpts, this unroll repeats act strange anyhow :-(.

Reply

• Jun 6, 2020 - 15:50
Status PR created ⇒ fixed

Fixed in branch 3.x, commit c5de914336

_Fix #305656 Two piano instruments shown for a single piano part after save/load

Prevents adding the same Part object twice to the same Excerpt by not adding a
Part for every staff but check how many staves each Part has and write only
the Part for first staff.

To decide whether Tracklist elements has to be written to the MSCX file,
Score::writeMovement() is now using the number of staves of a part instead
the number of Parts (which used to be the same but was wrong)._

Reply

Fix version
3.5.0