Instrument change should be able to apply to multimeasure rest
The most usual (I can't imagine any counter-examples) place to have an instrument change is at the start of a series or rests, so that the player has time to make the change. The current behaviour means that when one places an instrument change in its most logical position, say at the start of a period of 8 bars rest, if multimeasure rests are enabled MS insists on the instrument change being placed in a single bar rest, followed by a 7 bars multimeasure rest. It is impossible in such a case to have the instrument change at the start of an 8 bar multimeasure rest.
I suggest that instrument changes, like tempo text, should not force a break in multimeasure rests.
If there are counter examples where it makes sense to have a break, the user would be able to achieve this via the Bar Properties.
Comments
I agree with what I believe you are trying to say, which is that an instrument change should break multimeasure rests in exactly the same way that tempo text does. At first, it looked like you were saying that an instrument change should not break multimeasure rests at all, which I do not agree with.
See https://github.com/musescore/MuseScore/pull/5443.
In reply to See https://github.com… by mattmcclinch
Provided we can eliminate the break if the instrument change is in the first measure of a run of rest bars, I will be happy. Having an instrument change after the first bar of the run is not going to happen very often if at all. Why ask the player to wait to make the change? Unless it is for choreographic effect. (eg. Bar 32, the sax section puts down their saxes and ostentatiously take up kazoos).
Fixed in branch master, commit 2d816306da
_fix #296329: Instrument change should be able to apply to multimeasure rest
Resolves: https://musescore.org/en/node/296329._
Fixed in branch master, commit 5a0ad44cfb
_Merge pull request #5443 from mattmcclinch/296329-instrument-change-mmrest
fix #296329: Instrument change should be able to apply to multimeasure rest_
Automatically closed -- issue fixed for 2 weeks with no activity.