Bad tie lengths on mirrored end notes
Windows 10, GIT commit: fecf0a7
Discovered while working on #187151: Hairpins shifting out of position on systems containing ties from stem.
1) Load attached score
2) examine first tie
Result: tie is *way* too short (barely even visible at all):
This case has never worked correctly that I can tell, going back to when I first added the minimum tie length enforcement well before 2.0 beta (and I doubt it was any better before that. It is a bit contrived, in that normally if the end note is mirrored to the left, so will the start note, and the tie length will seem OK, as in the second example.
Still, it shows a flaw in the logic here. Simply removing the qAbs() here fixes this case:
https://github.com/musescore/MuseScore/blob/2.1/libmscore/chord.cpp#L18…
But I would want to understand better why I thought that was a good idea originally before comitting to this - I suspect some other case gets broken. On the other hand, I know I also modified the handling of seconds shortly after this.
BTW, logically, we should also factor in the 0.12 whether or not there is a non-zero X offset. But doing so seems to create unnecessarily long ties in cases, like if I added one to the the "D".
| Attachment | Size |
|---|---|
| back-tie-seconds.mscz | 4.23 KB |
Comments
See https://github.com/musescore/MuseScore/pull/3143. Turns out the lengthening that occurs if I add a tie to the "D" in the second case above is not a problem; it's actually correct. Even though it's not needed because of the stretch that is ultimately applied to this measure, the extra space to enforce the minimum tie distance *does* need to be allocated, and that extra space gets stretched just like any other extra space. This is something that affects all ties, and is indeed why the tie in #187151: Hairpins shifting out of position on systems containing ties from stem adds space even though it clearly isn't needed here either. In very crowded situations, the same tie actually *would* need the extra space, and currently it isn't being allocated. So, this *is* the right fix.
For 3.0, this all needs to be revisited to work with the new shape mechanism, which I still haven't looked at in any detail. I see Chord::layoutPitched() - the function that allocates the extra space for ties - still looks essentially unchanged. Not sure what the status of that is, but I will investigate after 2.1.
Fixed in branch 2.1, commit 461e706896
fix #188461: tie length ending on backnote
To be checked in master.
Same problem exists indeed, but same fix doesn't work. So I guess there is more going on here I need to investigate. The minimum tie length code is totally ineffective currently, presumably because this function (Chord::layoutPitched()) isn't really what is being used to allocate space.
Revisiting this, I realize that the new layout algorithm and the removal of Chord::layoutPitched() from this particular equation means that the code I added long long ago to enforce a minimum tie length no longer functions at all. So I've reopened[#2316]. Once that is addressed, we can take another look at this.
#2316: Small ties? Apparently so...
Also, when editing the slur "shape" with the grips, it is not possible to select it again.
For me, the file in the original report looks fine now, so the new simplified small tie code for 3.0 avoids the logic flaw that led to the problem in 2.0x. However, I can confirm it is often difficult to select an edited tie. Not just this particular case, but any edited tie. I don't think that is related to this code, though; it was the case in the first beta too. Apparently somehow we are still seeing the default layout of the tie, because it works to click where it used to be. I'll file that separately, but I think the issue here is fixed.
Automatically closed -- issue fixed for 2 weeks with no activity.