Update on wandering hairpins, trills, and other lines
As discussed in other forum threads and in the issue tracker, there are known but hard-to-pin-down problems with hairpins, trills, and other lines occasionally seemingly to randomly change positions after a save and reload. I have been working on this, and so far I have identified two specific situations where this problem can be reproduced. I would love it if people who have experienced this problem can check their scores to see if it seems the cases I have identified cover your situation, and report back here. Most importantly, if you think you have score that exhibits the problem but is *not* covered by one of these two cases, please post it and describe how to reproduce the problem.
Here are the two cases I have identified:
1) a score with a staff space value other than the default of 1.764sp and that uses repeat barlines - see #109021: Hairpin and other symbols are shifting when relayout occurs
2) a score with a key signature change that is *not* preceded by an explicit double barline (only the one that is automatically generated at the end of the previous system if the key signature occurs right at the start of the next) - see #180991: Layout jump due to bad cautionaryWidth() calculation
It is important to note the problem doesn't affect all scores that fit these descriptions. But the measure with the repeat barline (case #1) or key signature change (case #2) has its size calculated incorrectly when the score is first loaded, and if the system containing that measure is right on the edge of being able to fit another measure or not, that discrepancy can make the difference, and this is what triggers further problems.
In both of these cases, only hairpins or other lines *after* the repeat barline or key signature change in are affected, and only ones whose position had been manually adjusted. Also in both cases, the "wandering hairpin" is the most troublesome thing that goes wrong, but this is actually just a side effect of the actual problem: a measure somewhere in the score that is on one system when the score is saved but another when you load it (and then snaps back to its original position as soon as you do anything else).
Again, right now I know of these two cases where this can happen. The nightly builds for 2.1 already include a fix for case #1, and I have implemented a tentative fix for #2 as well. If there are other cases, we can try to take a look at those as well, but if it's going to happen for 2.1, we'd need to do this ASAP. So again, I ask people experiencing these problems to check your scores and let me know what you find. And if you have a score that suffers from this problem but seems to *not* be covered by one of those two cases, please post it here!
Comments
I've managed to reproduce one other case of measure jumping, shown in this score:
https://musescore.org/en/node/88321#comment-444706
This one isn't just on first load but on *every* edit, which is actually good news in that it's pretty hard to miss so you're hopefully more likely to work around it by adding a line break yourself (that's actually the case for some/most scores affected by #2 above).
I think this one probably also due to the courtesy signature (before measure 273), but here it can't be the double bar throwing things off, because it is explicitly present (and hence my fix for #2 doesn't help). I suspect it will turn out to have to do with the use of Hide empty staves, which results in some staves not being shown and thus their courtesy signatures aren't needed but we don't which staves are going to be empty and hence not until too late. If I'm right about that, I fear this one won't have an easy fix. I also doubt very much I'll have time to look at this one further right now.
Both case #1 and case#2 from my original post are now fixed in the 2.1 nightly build. Testing is highly encouraged. I'd like to get some sense of whether or not we've now fixed "most" of the problems people are seeing or not. Note if your hairpin has already wandered and you've saved without fixing that, don't expect them to go back to where you wanted them. But if they were correct last time you saved, they should hopefully remain correct now.
Also if I've somehow inadvertently broken something, now is definitely the time to let us know!
Another reproducible case identified, this one triggered by a certain type of tie that occurs on the same system as the hairpin or other line - see #187151: Hairpins shifting out of position on systems containing ties from stem. This one appears to have been introduced at some point between 2.0.2 and 2.0.3, but even though we know the trigger and in fact the actual date it apparently broke, I'm still not sure what is going on yet. Would love it if people who have experienced the problem could check out that report and see if it seems relevant to you.