Is the fermata working as expected?

• Aug 7, 2019 - 14:10

Usually a fermata or pause mark is used to cause the corresponding note or rest to be longer by an indefinite amout which remains to the discretion of the player (and this is what several notation handbooks say, such as Gardner Read's and Elain Gould's). MuseScore implements it as a tempo reduction whose the specific proportion can be chosen from the inspector. This would be a good solution if there were only one note affected by the fermata. The problem arises in situations as the following: Consider a score with two staves, the upper one has a whole note with a fermata, and the lower, two half notes with a fermata on the second one. Current MuseScore's playback applies a tempo reduction starting from the first fermata (first beat), so the first half note from the lower staff is affected even if it doesn't carry a fermata. Then, the second fermata surprisingly applies a new tempo reduction over the first tempo reduction instead of applying the tempo reduction specified in the inspector to the original tempo. The overall effect is not a pause but a slowdown, sort of artificial ritardando. For a single note it is equivalent to a pause because there are no notated rythmical events during the time span of the note.
This behavior is awkward and, I believe, contrary to what a human player would (and has been taught to) do .
Of course there are situations where the note with a fermata is preceded by a ritardando, but it is not always the case.
In the absence of a specifically notated ritardando or tempo change (or one decided by the player), the intended result of such notation would be that the first half note keeps the original tempo of the piece, and the second one is extended to last more than notated.
I'm aware that the developers must have been confronted with a tough one when considering the problem of multiple concurrent fermatas and they opted for this straightforward solution, but I believe it can be improved.
In what follows I try to propose a possible alternative solution.
First of all, whenever a fermata appears on any note, at least one fermata should share with it part of its time span in all voices and staves of the system, i.e., on some note within the notated duration of the note, otherwise there is a contradictory and hence incompatible requirement: two simultaneous notes or rests are required to have different durations. The current solution is particular in that it allows violating this norm, since a single fermata triggers a tempo slowdown which affects all staves, thus encouraging what is really a bad practice (omitting the remaining necessary fermatas). But it does so with another bad practice: changing the tempo of what is written without any tempo change. (See attachment for examples of inconsistent and consistent fermatas.)
That said, I'll assume this notational rule is followed and let's start with the proposed algorithm.

1) Number each fermata first by initial time and in case of simultaneity, by staff order
2) Create a table or matrix containing initial MIDI time and final MIDI time for each fermata, i.e., corresponding to the note or rest it is applied to (a row per fermata)
3) For each fermata change the initial time by the initial time of the next fermata with an initial time strictly different and not greater than its final time. For instance, if there are two simultaneous notes with fermatas and then a third one starting after the other two, the initial time of all will be that of the third note (notice that no fermata can start after all the others ended because it would be alone).
4) The last step creates a set of intervals. Intersect all the intervals. The only valid places to add extra duration are the time regions where all voices have a fermata.
5) To compute the duration of the extra time, add to the previous table a column indicating the total expected duration considering the setting the user has chosen in the inspector for each fermata.
6) The settings may be incompatible if care has not been taken to devise a fully consistent group of settings, Don't care, select the greatest since it will be the one that conditions the rest.
7) Add the difference of time between the desired and the notated duration of the corresponding note or rest to the valid interval obtained in 4. If more than one, the extra time could be distributed proportionally to the duration of the subintervals.
8) Convert the combined time (original of the valid interval + maximum increment) to tempo (this is to implement the fermatas using the resources available from MIDI
9) Apply a tempo change at the beginning of the valid inteval and don't forget to restore the original tempo at the begining of the next note or rest (i.e., end of valid interval)

In the attached example a sketch of this idea is shown.

As a final comment, some check should be done that the rule for using fermatas is satisfied. Currently the user (especially the inexperinced one) has no clue that they are doing things wrong.

Attachment Size
Examples_with_fermatas.mscz 10.57 KB

Comments

When a conductor conducts the orchestra, he cannot moves separate fermata for everyone.
Timing should be made according to the fermata of the largest note value.
And only that fermata should contain the time-stretch value. Others will only for display.

In reply to by Ziya Mete Demircan

I’d say if you have a half and an eigth plus dotted-quarter rest, both notes under fermata, the conductor can very well first stretch the eigth (with its own value), then the half that has already started (I’d notate a fermata on the rest then as well but not giving it an explicit stretch value).

So the total value of the stretch is the largest sum of concurrently-happening stretch sequences, but within that, smaller values can be stretched as well.

In reply to by mirabilos

Sorry I'm reading this several months later. I don't quite understand your example. Do you have three voices, one containing a single half note, a second one containing an eigth note followed by a dotted quarter note rest simultaneously with the half note, and a third voice containing, for instance, 16th notes? Are the fermatas on the half note and on the eigth note but not on any of the 16th notes? If this is the case, the third voice should contain at least one fermata, and that fermata or those fermatas would be the only one(s) to stretch. I insist: a fermata isn't a tempo reduction but a note with a longer duration than the written one. If the composer wants to control the tempo, (s)he should write a ritardando instead. Otherwise they should clearly indicate which notes to stretch applying a fermata.

In reply to by fmiyara

Sorry, but your example in the OP is unrealistic and unplayable. A fermata is shorthand. A signal to the group to watch the conductor. Just like a tempo chance , or any other marking. Whether or not MuseScore can figure it out is not important. I can't imagine writing anything like your examples. Ever. As far as software is concerned, of course it is a tempo change. As far as real players are concerned, they follow the conductor. So, two scores are needed. Not a big deal.

In reply to by bobjp

First of all, fermatas exist also in keyboard or chamber music, so not necessarily there is a conductor. The soloist, chamber group members or the conductor will have to decide what to do. My first example is indeed unplayable because it doesn't follow the rule that all voices must have a fermata on one or more notes that coexist with a note in other voice which has a fermata. Any correctly notated example, no matter how rythmically complex it is, is playable after some thought.

Please check the Urtext version of Bach's WTC Book I, Fugue VII, you will find at the end four fermatas, one for each voice, the first two at the beginning of the measure. the two last (internal) ones on the second half notes. The same happens with Fugue XX. Book II, Praeludium XI has a more complex use of fermatas, with three occurring at three different beats on the last measure. None of them require a drastic change of tempo as Musescore will do.

I acknowledge that in those examples there is a slight stylistic rallentando during the first notes of the last measure, but you can check that Musescore wiil brutally slow down to a new lower tempo right away after de first fermatas, and there is nothing that can be done except ignoring them, i.e., asigning a x1 duration change.

Another example, Beethoven's Sonata op 27 No. 1, at the end of the first movement. There is whole note chord on the right hand, and on the left hand a quarter note rest followed by a dotted half note. The rest is expected to keep the same preceding tempo. Musescore wil make the tempo assigned to the fermata on the whole note to prevail, causing an undesired tempo reduction.

I think it is important that MuseScore allow users to control the effect of a fermata without applying an unnecessary tempo change to all the notes not having a fermata

In reply to by fmiyara

In a situation like you mentioned, time-stretch shouldn't be applied until the last note with the fermata in that measure is reached. But the duration value of this note may be very small (16th, 32nd, 64th). Therefore, the time-stretch value must be taken from the longest note and should be calculated accordingly. Otherwise, the desired fermata effect will not occur.
So (in the code to be written to implement them) two rules have to be taken into account at the same time.

PS: What I'm talking about are my thoughts based on the way the software works. For a musician, you wouldn't have such a problem in real life.

In reply to by fmiyara

In the case of the Beethoven, if I were writing something like that, I would put the fermata over the dotted half note instead. Although at the end of a piece I'm not sure how important it is.
I agree that software doesn't always read music the way we might like. But software doesn't have any idea what it is doing. It doesn't have to. It's up to the user to decide. Beethoven didn't write for computers. That's why his music is marked the way it is. Perhaps we should stop expecting computers to perform musically.I think that there are other far more important problems of computer notation that need to be fixed.

In reply to by bobjp

I'm afraid I was not clear enough, sorry. Beethoven actually put a fermata on the chord and another fermata on the dotted half note, as you correctly point out. But the way MuseScore plays the passage is incorrect, since it assumes that the stretch suggested by a fermata starts at the beginning of the note, when there are plenty of examples (such as the ones I've provided and many more) where it is clear that the stretch may start at the end or even in the middle of the note. This assumption results in an abrupt tempo change right after the note onset so, in this particular case, the beginning of the dotted half note is delayed. Beethoven isn't thinking of a rallentando, otherwise he would have indicated it. He only wants that the notes have a longer duration than the written one. By the way, at the end of this particular movement it is of the utmost importance, since there is an attacca subito
Software doesn't know what I want, but I certainly do! Software should help me attain my ideas without an inordinate bunch of workarounds.
Fortunately the historical mantra "MuseScore is a notation software, not a [fill with any wishlist]" is coming to an end. A notation software that doesn't allow reasonable accurate playback with decent musical intelligibility won't be very popular. The popularity of MuseScore (unlike Lilypond, for instance) stems from the added value of reasonable playback capabilities.

In reply to by fmiyara

Wait. As I understand it, MuseScore won't do anything with a fermata unless you define it in the inspector. So don't do anything with the fermata on the whole note. Only the dotted half.
Sorry but I know guys who work professionally with DAWs. They won't even listen to anything produced by notation software. That's not likely to change anytime soon.

Do you still have an unanswered question? Please log in first to post your question.