I thought it was important that scores saved in one 2.0 patch release appear basically the same in another. Don't forget about the other direction: if a score is created in 2.0.4 with multimeasure rests automatically broken by fermatas, and then that score is opened and printed from 2.0.3, the fermatas won't appear. Whereas if this commit is rolled back and the status quo from 2.0–2.0.3 remains, the 2.0.4 user will manually break the multimeasure rests and this problem won't arise. This fear is exactly what keeps Recorder485 from updating.
Comments
On following your link, this doesn't make sense to me.
A fermata demanded by the composer SHOULD be notated. If you want to mark up your part go ahead.
Therefore I would think that MM rests should be broken by a fermata (I'm not sure if they are now).
Or perhaps I do not understand your meaning?
MM rests are not currently broken up by fermatas the composer/user has notated in the middle of those rests. They should be.
Hence, Multimeasure rests should account for fermatas.
Fixed in branch master, commit 42b9a20e4b
fix #121051: Multimeasure rests should account for fermatas
Fixed in branch 2.0.4, commit 4eabccea81
fix #121051: Multimeasure rests should account for fermatas
2.0.4 is risky—this would change 2.0.3 scores without warning.
but otherwise it 'eats' fermatas, so having the fix seems the lesser evil
I thought it was important that scores saved in one 2.0 patch release appear basically the same in another. Don't forget about the other direction: if a score is created in 2.0.4 with multimeasure rests automatically broken by fermatas, and then that score is opened and printed from 2.0.3, the fermatas won't appear. Whereas if this commit is rolled back and the status quo from 2.0–2.0.3 remains, the 2.0.4 user will manually break the multimeasure rests and this problem won't arise. This fear is exactly what keeps Recorder485 from updating.
Automatically closed -- issue fixed for 2 weeks with no activity.