Sound in Instrument change not preserved upon re-access of score
1. Open attached score (produced in 1.3).
2. Drag 'Instrument' (from the Text palette) onto the first note of bar 2.
3. 'Mixer'.
4. Change sound to something else.
5. Open another score.
6. Open original score.
7. Play.
5. 'Save'.
6. 'Close'.
7. Re-open the score.
8. 'Play'.
Expected result: The sound and Mixer entry of the instrument change is what you selected.
Actual result: The sound and Mixer entry of the instrument change is harpsichord.
Using MuseScore 2.0 Nightly Build (f06636c) - Mac 10.7.5.
Attachment | Size |
---|---|
Sound in Instrument change not preserved upon re-access of score.mscz | 1.41 KB |
Comments
I'm surprised you called this "minor". If we are to support these sort of "partial" instrument changes, then the changes needs to be preserved, I'd think.
It seems that when writing the instrument change element, the mixer channel change is not taken into account for some reason. I don't know much about how this stuff is handled, but I'm going in.
https://github.com/musescore/MuseScore/pull/698
The problem is that the InstrumentChange element has its own private copy of the instrument that is updated on a true Change Instrument command but not on a patch (or other) change via Mixer. So when the file is written, what is written for the InstrumentChange element is the instrument info with no consideration for mixer settings. Mixer settings update only a separate copy of the instrument contained in the part's instrument list.
I feel the right answer is not to let these get out of sync in the first place, but that's either ugly or a more architectural change than I want to make.
The easier fix for me is to not actually write the InstrumentChange's copy of the instrument. Instead, I find the copy of the instrument in the part according to the tick position of the InstrumentChange element. This is simple and works, even though it feels a bit wrong to have this essentially orphaned copy of the instrument in the InstrumentChange element.
Fixed in 1b9f822f9c
Automatically closed -- issue fixed for 2 weeks with no activity.