Ties are poorly laid out inside clusters
See some examples attached
| Attachment | Size |
|---|---|
| MuseScore3_2019-01-04_17-13-38.png | 23.77 KB |
Do you still have an unanswered question? Please log in first to post your question.
See some examples attached
| Attachment | Size |
|---|---|
| MuseScore3_2019-01-04_17-13-38.png | 23.77 KB |
Do you still have an unanswered question? Please log in first to post your question.
Comments
This is indeed a known limitation of our layout algorithms, one of the places where manual adjustment is still often needed.
In reply to This is indeed a known… by Marc Sabatella
I've just hit this. It's very messy to achieve manually. This is what I am trying to achieve:
![Screenshot from 2019-06-05 23-36-07.png]( "Screenshot from 2019-06-05 23-36-07.png")
In reply to I've just hit this. It's… by richardm999
It seems to me that automatically detecting the cases that will benefit from this approach is probably harder than adding a checkbox to the Inspector to that just told MuseScore to not bother trying o do anything fancier with the tie, and just do the above.
In reply to It seems to me that… by Marc Sabatella
I think that approach would be very helpful.
In reply to It seems to me that… by Marc Sabatella
I'm not sure if it's really hard to detect. Don't focus on the lines themselves, cluster notes are a good heuristic. Typically if it contains 2nds (alternating left and right) it usually produce bad ties. OK maybe the rule should be a little more nuanced but it doesn't seem impossible.
In any case, even just a checkbox to get "basic" ties would be golden.
I'm spending crazy amounts of time fixing my ties manually, it's really time-consuming.
In reply to I'm not sure if it's really… by jods
"I'm spending crazy amounts of time fixing my ties manually, it's really time-consuming."
I agree: currently I am reviewing songs with piano accompaniment, and fixing the layout of clustered ties in the piano part is ... well, repetitive and tedious. And anything repetitive should in theory be open to a programmatic solution? I would have a go, but sadly I never learnt C++.
The situation is even worse where dotted clustered notes are involved, because the left-hand anchor can collide with the dot in too many cases.
In reply to "I'm spending crazy amounts… by DanielR
augmentation dot and tie always collide when note is on a line and stem and slur is up
In reply to augmentation dot and tie… by Jojo-Schmitz
Yes, and vice versa, also when the note is on a line and the stem and tie are both down. Is it being fixed?
In reply to Yes, and vice versa, also… by neo-barock
no, not fixed yet. And not in the works, as far as I can tell. Not in the issue tracker either, I think?
and https://musescore.org/en/node/292782 is not an issue, but just another forum topic...
#292784: Upper-voice-dotted 2nds positioning issues now is though ;-)
In reply to no by Jojo-Schmitz
The dot-tie collision problem is in the issue tracker since 2015: https://musescore.org/en/node/45576
In reply to The dot-tie collision… by neo-barock
or #45576: Tie on same side of staff/ledger line as augmentation dot = collision
In reply to I'm not sure if it's really… by jods
Would you agree with this assessment:
If the chord is nothing but two notes a second apart, and there are not multiple voices, the defaults generally work pretty well. The ties are in opposite directions and stay out of the way OK. Things get iffier if there more than just the one second, or there are multiple voices (which force stems in the same direction. At that point, it really gets more difficult to predict.
So the best rule I could propose might be, use the current rule for chords with no seconds, or for chords of only two notes with only a single voice. But for chords containing seconds and having either more than two notes or multiple voices being present, use the alternate rule where ties attach outside of the full chord.