Stretched-fermata timing mishandled in 3.0 Beta

• Dec 3, 2018 - 15:21
Reported version
P0 - Critical
S3 - Major

The second note of the enclosed 2-note score (prepared in MS2) cuts off way prematurely in MS3. Can't migrate scores or post new ones if workaround-timing is necessary, as it will break them again when it is fixed.

Attachment Size
BreveTest.mscz 3.96 KB


In reply to by Marc Sabatella

I have not played with it enough (I suppose the whole point of the Beta it is to encourage struggles, not scare away!) -- Gertim (@SDG), who first found this, has. I did have massive problems with final measure tempo changes on the one V3 score I have posted, but stupidly assumed it was my fault and even more stupidly beat it into submission.

In reply to by Marc Sabatella

Yes, it's really blocking my productive use of the app. My second posted 3.0 score is devoid of tempo control because of it. Even attempting to cajole it with a hammer doesn't bang it into shape. Please note that even new fermatas in such a score cannot be made to behave properly. Sometimes they behave erratically (don't do same thing every time played). They are truly broken.

But - only for imported scores? Or can you reproduce this behavior from scratch in 3.0? So far I could not. If you can, steps to reproduce the problem (starting from a working step then some particular step takes it to a non-working one) would be very helpful.

In reply to by Marc Sabatella

So far limited to imported scores, even COMPLETELY NEW FERMATAS in completely new measures. Every user has only MS2 scores at this juncture .... importing has to work completely. I wrote a significant piece yesterday, but it was started in MS2 and there is no way I can use (active) fermatas reliably or port it back (MusXML would lose the articulation work). (ps I love the new "pig nose" fermata!)

I had a fermata failure in 3.0 clean, but when I save it, it fixes it (so I can't attach it). Using a pan flute at quarter = 70, type three single quarter notes. Put a fermata on the middle one. Set it to 1.5 stretch. Works well. Add a trill. Timing goes to hell, becomes 4 times longer. Remove the trill. Timing still erroneous. Save the file. Timing fixed.

Interesting! Thank for all these clues, hopefully they will help. Right now we have around 70 issues identified that we want to fix before release, but of them only a small handful as real showstoppers to me. This is certainly one of them. Actually, both this and the other issue you opened about the weirdness we occasionally see with key signatures. Not everyone sees either of these, and they are proving hard to pin down so far, or they'd have been fixed already given how serious they obviously are when they do happen.

I don't have a fix yet, but I do understand a bit more about what is happening. The problem does not appear in a score with no tempo marking, but does appear if there is a tempo marking before the fermata. The fermata does not "see" the tempo marking and plays as if the default 120 BPM were in effect. And playback after the fermata similarly ignores the marked tempo and plays at 120.

The problem is not unique to 2.x scores, I can reproduce from scratch - but only after saving and reloading. it plays fine when I create the score, but fails in the same way after the reload. Deleting an re-adding the fermata might fix it, but deleting and re-adding the tempo makes it worse.

Taken together, this tells me somehow we are really messing up the tempo map on score load. I'm not an expert on this area of code, but this has gone on long enough, I'll see what I can do...

I took a look and see there were a couple of changes to this code a few months ago. I'm guessing it fixed something but broke this. I fear I'd probably make it worse, but I'll make sure it gets looked at.

So to be clear: this is a problem for all scores with fermatas, if tempo is other than 120. Add fermata, set playback, save reload, play - tempo is wrong from fermata on. That's why this is marked critical.

That score does indeed seem to play correctly for me using a build with this change. Thanks to dmitrio95 for figuring out a solution!

We would love it if you could help us test! I assume a nightly build will be available soon. I plan to be hitting on this too over the next couple of days as I can, too. My hunch is that if there is a problem it would involve repeats, including perhaps DS voltas, etc. But the repeats in this piece don't seem to cause a problem, and most likely, the fix really is good.

Watch this page: Ignore the tempting-looking "special" build in boldface at the top of the list. When the next down is something more recent than "12-22-0847", grab it!

BTW, the changed code is more about the processing of tempo than of fermata - basically, moving the tempo processing earlier. So if there are are problems, they could possibly occur with mid--score tempo changes even in the absence of fermatas.

Thanks for checking!

Actually, it doesn't hang, it just pauses a very long time :-). Same in the RC, so not a regression introduced by this change. It doesn't pause as long in the RC only because the tempo is too fast to begin with. but relative to the tempo, it's the same.

Here I think we have a very specific case, something about a fermata with a very long stretch (14) being applied to a note in another voice while a fermata is still applied to another note being held simultaneously. Very much a corner case it seems to be, probably worth submitting as a separate issue.

When I try to play that score (the CelloPrelude.mscz version that was attached to the comment above) I also meet that very long note in the 17th measure. This indeed doesn't seem to be caused by my PR as it was present before that.

I also met another bad issue with that score: MuseScore can randomly crash on playing that score. The most reliable way to reproduce the crash I managed to figure out is to edit something in 16th measure (for example, repitch the first note) and play the score from that note to the problematic fermata. After several attempts (3 or 4 usually) MuseScore crashes when playback comes to that fermata (backtrace points to mscore/seq.cpp:936). Once MuseScore crashed for me also before playback got to that measure but I don't know whether it is reproducible. This problem is also present before applying my patch but this sounds like something not very good.

Sorry, to clarify - I said it also pauses way too long in the RC, not that it plays too long in 2.3.2 or on So, a change compared to 2.3.2 for sure, but not a change just introduced by this fix.