MuseScore icon indicating copy to clipboard operation
MuseScore copied to clipboard

[MU4 Issue] Changing default time stretch of fermata in MU4 to 200% is a regression on MU3

Open SteveBlower opened this issue 2 years ago • 4 comments

Describe the bug

The default time stretch in MU 3 was 100%. In MU4 it was changed to 200%. Having a default time stretch of anything other than 100% is a great inconvenience when there are fermata on multiple instruments as Musescore honours the longest of them. If a duration shorter than default 200% is required then the time stretch on ALL of the simultaneous fermata have to be shortened for the shortening to take effect in playback.

Additional context Default was changed as a "fix" for this closed issue #13464

SteveBlower avatar Dec 24 '22 18:12 SteveBlower

Related to #15329.

Basically, the problem is that we need to determine which fermatas on different staves / voices belong together, so we need to "consolidate" those. Getting this perfectly right in every possible case seems non-trivial to me, but everything is solvable. We may also want to provide a way to control this to the user.

Keeping the default time stretch at 100% would be annoying because then fermatas won't seem to work at all (until you figure out that you need to enable a mystery thing called "time stretch" in some hidden popup somewhere, as a new user might experience it). And unless there is any other use case not described here yet, the only use case would be a workaround for the "consolidating" problem. I'm not a fan of making sub-optimal changes in favour of a workaround for another bug; I'd rather focus on fixing the other bug.

By the way, for inspiration: Dorico's solution to the consolidating problem is a very rigid one: they make fermatas a kind of system object, that is mandatorily applied to all voices on all staves. You can then move then to a different note for each voice individually, but hiding is not possible. Not ideal either, but still quite a nice solution.

cbjeukendrup avatar Dec 24 '22 19:12 cbjeukendrup

Dorico's system, dare I say it, is very sensible; fermatas should be a system object (and appear on all staves), though we do need to be able to override this behaviour.

oktophonie avatar Dec 26 '22 12:12 oktophonie

A complication with any sort of system behavior is, the fermatas may well not be on the same beat. Like, one staff might have a whole note with fermata, another four quarters with a fermata on the last. So the first fermata is actually on beat one, the last on beat four. This inconvenient fact causes any number of complications in the design.

If we didn't want to go the full-on Dorico approach, another possibility is to simply make any change to one fermata apply to all fermatas within the beat range affected. Kind of like how key signatures or barlines are really per-staff internally, but most operations on them nevertheless are propagated to all staves.

MarcSabatella avatar Dec 26 '22 17:12 MarcSabatella

A complication with any sort of system behavior is, the fermatas may well not be on the same beat.

This problem is solved by Dorico's model to some extent, but actually in a slightly different way than I remembered. Fermatas do have a "tick" (to use MuseScore's terminology) that is the same for all staves, and on which note the fermata appears depends only on this tick:

https://user-images.githubusercontent.com/48658420/209572406-7c4f7320-53a8-4951-9222-aaa9212bf274.mov

That makes it impossible to create a situation like this: Scherm­afbeelding 2022-12-26 om 20 00 14 while I think that this is not a nonsensical situation.

So maybe we need to choose a slightly different solution.

cbjeukendrup avatar Dec 26 '22 19:12 cbjeukendrup

A complication with any sort of system behavior is, the fermatas may well not be on the same beat. Like, one staff might have a whole note with fermata, another four quarters with a fermata on the last.

However, all fermatas should end at the same time. Think what a conductor would have to indicate in both those cases - beat 1, 2, 3, hold on 4 ... and release for beat 1 of the next measure.

The "impossible" example in @cbjeukendrup's post is nonsensical, I would suggest. What could the conductor do - instrument 1 has a fermata on beat 1 so hold beat 1, meanwhile instruments 2 and 3 are looking puzzled - when is beat 2 going to happen? Or don't hold beat 1, but hold beat 2, meanwhile instrument 1 is now looking puzzled - what happened to the fermata? Or hold both beats 1 and 2 and everyone looks puzzled!

It looks like Dorico's method also allows nonsensical notation to be produced with the example given requiring a hold somewhere or perhaps on 2 different beats but no way for the conductor or players to know just by reading the score.

The addition of a fermata to note or rest X should have no effect on the duration of notes that end before note or rest X. A note or rest that also ends at the same time as note X must also have a fermata. A note that would otherwise end after note X must be split into shorter durations so that a there is a note that ends at the same time as note X but which is tied to other notes to complete the desired duration.

Perhaps this issue should migrate to the discussion area so that the precise logic can be explored further.

SteveBlower avatar Jul 12 '23 20:07 SteveBlower

I agree @cbjeukendrup's second example (where two players have the same duration note on the same beat, one with a fermata and one without) is something you couldn't even expect human players to make sense of, so to me it doesn't really matter what the computer playback is. In general the rule seems pretty simple to me - extra time should always be added to the end of any note with a fermata, and the amount of extra time depends on the shortest note at that beat position. Which would simply cause that second example to be played with both the first and second beat to be extended to x% of the beat length, which seems perfectly adequate and probably what human musicians would end up deciding on (after much swearing at the composer/typesetter...).

wizofaus avatar Jul 21 '24 22:07 wizofaus

@wizofaus Can you clarify what you mean by

the amount of extra time depends on the shortest note at that beat position

Do you mean that the duration should be calculated as a %age of the duration of the shortest note ending at that beat position? - i.e. if you have a half note on beats 1 and 2 and a quarter note on beat 2, both of which have a fermata, the duration should only take into account the properties of the fermata attached to the quarter note and if say, the time stretch of the fermata on the half note is set at 250% and the time stretch of the fermata on the quarter note is set at 150%, the duration would be extended by the duration of an eighth note. Would this need someway of indicating to users which fermata was "in control"?

Another thought: would it be better to express the extension of duration of a fermata in terms of beats rather than %age of the duration of the note to which it is attached? My guess is that most musicians consciously or subconsciously think that way when they encounter a fermata. So, under playback properties a fermata would have "Extend duration by [...] beats" instead of the time stretch parameter.

SteveBlower avatar Jul 26 '24 11:07 SteveBlower

Yes, in that scenario, I'd expect the fermata to be based purely on the 1/4 note - i.e. the second 1/4 note beat should be stretched by 50% (and the first not at all). But you can always change that 150% to be more or less as needed. In a more complex scenario where where you had a 1/2 note with fermata in one staff/voice, and in another you have a 1/4 note with a fermata and then a 1/4 note without, it would be the first beat that would be stretched by 50%. But if you deleted all those 1/4 notes, then the 1/2 note itself would be stretched by 150% (which would result in a longer time stretch). What's a "beat"? What if you had the above but the time signature was 6/8?

wizofaus avatar Jul 26 '24 12:07 wizofaus

What's a beat - deep question... it all depends ...

So yes, my suggestion is half baked. Let me put it back in the oven for a while.

SteveBlower avatar Jul 26 '24 13:07 SteveBlower