Tie forces break but slur does not

• May 9, 2018 - 04:57

I'm transcribing a piano concerto where there are tied notes in the orchestra part (in this case, it's a piano reduction of the orchestra part).
Here is the section in question (measure 1) with ties:
Screen Shot 2018-05-09 at 12.54.58 PM.png
I tried it with slurs instead:
Screen Shot 2018-05-09 at 12.54.42 PM.png
The tied notes seem to take up more space than the slurred ones for some reason. However, what's more concerning to me is that it's able to force the staff to break to the next line even though there are significantly less notes than the piano part above it. I've tried decreasing/increasing stretch, but that doesn't seem to help. Could anyone help me remove the break or at least explain to me why this is the case?

Attachment Size
tie.mscz 15.55 KB


I think the slurs are positioned just slightly differently to ties. Ties go from near the right-hand side of the first note to near the left-hand side of the next. Slurs go from a slightly different start to a slightly different finish point (near middle of the notehead in this example). The tiny difference is enough to force a break following this very packed measure.

As suggested, slightly reduce the spacing. If you only want to reduce spacing for this measure, try slightly reducing the Leading and Trailing spaces of the notes.

Ties do indeed take slightly more space than slurs in some cases, because a) they attach to the interior of the notes rather than the centers, and b) there is special code to prevent too-short ties in crowded situations, and this can actually slightly affect the spacing even in less crowded situations. And unfortunately, the latter point seems to be the problem here - the extra space allocated to prevent a too-short tie on the bottom part isn't actually needed here because of all the other notes in the top part, but it nevertheless gets in the way. You can actually "fix" that in this case by going to Style / General / Slurs/Ties, and reducing the "Minimum tie length", although chances are you won't like the results elsewhere.

In reply to by Okoyos

Sure. It's actually not so much a bug but a flaw in the design - that is, the inevitable side effect of the method we use to ensure minimum tie lengths, and the same flaw extends to some other similar calculations. But I know 3.0 will handle spacing very differently and it's possible there would be a better way of doing this sort of thing that doesn't suffer this problem.

In reply to by Marc Sabatella

I'm trying to open this file in a 3.0 nightly build (c145fda) to make the bug report more relevant, but the page renders completely blank (no score, no anything), and I'm having a hard time recreating the issue. I don't know much of the changes made to 3.0, but something (new or old) seems to be broken.

Do you still have an unanswered question? Please log in first to post your question.