Stretched-fermata timing mishandled in 3.0 Beta

• Dec 3, 2018 - 15:21
Reported version
3.0-dev
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
active
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

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.