Stretched-fermata timing mishandled in 3.0 Beta
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
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 |
Comments
I can reproduce with this score but not one I create from scratch. As far as I can tell, the problem is something about the treatment of the tempo in scores imported from 2.x, sometimes it seems glitchy, see also #279268: Incorrect tempo playback of imported score with parts (although obviously parts aren't the issue here). Does this match your experience?
In reply to I can reproduce with this… 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 (No subject) 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 But - only for imported… 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...
In reply to I don't have a fix yet, but… by Marc Sabatella
Double thanks. Like many scores, the one in the last report uses hidden active fermate, exclusively, to manipulate tempo of individual notes.
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.
This patch makes this working properly, though I wonder what was the reason not to do that before: https://github.com/musescore/MuseScore/pull/4470. Maybe I am missing something though.
Fixed in branch master, commit e09a14ae35
fix #279296: apply tempo text before fermata time stretch
Fixed in branch master, commit 24020dad80
Merge pull request #4470 from dmitrio95/279296-fermata-time-stretch
fix #279296: apply tempo text before fermata time stretch
Does this really fix all known test cases? Does this score play as it does in MS2/online? https://musescore.com/user/1831606/scores/1828286 ?
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.
In reply to That score does indeed seem… by Marc Sabatella
Thanks. Please do notify me of Mac builds you want me to test.
Watch this page: http://prereleases.musescore.org/macosx/nightly/. 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.
ok (although this weekend is busy).
https://ftp.osuosl.org/pub/musescore-nightlies/macosx/MuseScoreNightly-…
In reply to https://ftp.osuosl.org/pub… by Jojo-Schmitz
Close, but no cigar. This score hangs in m. 17. Was terrific up to that point. And then I tried other fermatad notes in it and it played them incorrectly then crashed. This piece is posted among my cello offerings.
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.
In reply to Thanks for checking! … by Marc Sabatella
No. It plays fine right here: https://musescore.com/user/1831606/scores/1806656 , no "very long". I waited a good half a minute with the nightly. (Edit). I downloaded from there, and it is (very) ok ... on with my testing. Don't know what is bothering my local copy.
In reply to No. It plays fine right here… by [DELETED] 1831606
Passes all my tests (other than that problematic score whose online version passes when d/l'ed to nightly).
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 musescore.com. So, a change compared to 2.3.2 for sure, but not a change just introduced by this fix.
Automatically closed -- issue fixed for 2 weeks with no activity.