Tie on same side of staff/ledger line as augmentation dot = collision

Yep :-). There are worse problems too in cases where the chords contain seconds. Definitely still room for improvement in tie placement, although it is greatly improved over 1.3 already.

Also see this .

According to Gerou/Lusk ("Essential Dictionary of music notation," p144), "Ties should never collide with augmentation dots. Begin the tie to the right of an augmentation dot."

Ties collide with duration dots:

After correction:

came up again in https://musescore.org/en/node/113276

and again in https://musescore.org/en/node/113966

Came up again in https://musescore.org/en/node/262212

It probably not very hard to avoid the dot, what might be hard is preventing the mess that could result when you also throw in the possibility of seconds, multiple voices, etc.

Came up again at https://musescore.org/en/node/286957.

4 years old and this issue keeps getting reported. I summarised cases in 2 parts here https://musescore.org/en/node/292818 I don't know where the relevant code is, but it seems like it should be pretty easy to fix this. It would save an awful lot of time having to manually drag-reposition all these tie anchors.

The hard part is just coming up with appropriate rules for each and every combination of special cases - dots, chords, seconds, multiple voices, etc, as I said before - and to keep the code synchronized to make sure the algorithm to ensure minimum tie length continues to function as expected.

BTW, if you're literally dragging, you can definitely save time just using the cursor keys. Double-click, Shift+tab to change the focs to the first handle, Ctrl+Right to move by 1sp.

Thanks for the keyboard- based alternative. That might be faster for some people. It's not for me, because it requires moving my hand to and from the mouse repeatedly, which I find exhausting. Left hand on the keyboard, right hand on the mouse - zoom in, click and drag, zoom out - that is actually faster for me. Fixing all these cases is time-consuming any way you look at it. Without knowing how the code is organised, I have no sense for how complicated it may be, but handling the most common cases seems like it shouldn't be difficult. Many of the special cases would probably have to be fixed by hand anyway. So I don't really see any valid excuse not to fix the problem.

Mostly it's a matter of priorities based on benefit for the amount of work - there's lots to do, and we're mostly all volunteers here.

But, there is another consideration any time you change anything about the default layout, and that is, this may break scores that already applied manual adjustments. If you shortened the tie in an existing score, now it will be too short when your adjustment is applied to a new default. So we tend to be extra careful about that sort of thing.

Yes, "no excuse" is much too harsh because I I understand about the priorities, and I do appreciate that you have to think about backward compatibility. The fact that MuseScore 3 asks if it should apply auto-layout to old files is a similar case - and it is much appreciated that you cared to give the user-control over that situation. Once this issue gets addressed, providing a flag in files for it to prompt a similar warning would work, though I realise also you want to keep such warnings to a minimum, to me this clashing issue would warrant the bother.

I appreciate your understanding. The issue is deeper than that, though. Detecting an "old" format file requires bumping the file format version, which potentially makes the score not openable in older versions, and trying to maintain both the old and new layout algorithms with each change (in order to best import older files) gets more and more unsustainable the more such changes that are made. So it's not something one undertakes lightly, and I just don't see this issue as being worth the enormous upheaval of all that. There was a good window of opportunity for this sort of change 3.0 but no one brought it up during the several months of alpha & beta testing, so it didn't get looked at.

Realistically, there may never be another similar window where we knowingly change the file format and break compatibility completely, so it's more a matter of minimizing the pain by just designating one release as the one with a bunch of layout improvements that break a bunch of manual adjustments in older files but don't otherwise break compatibility. Rather than breaking things a little bit at a time with each minor release.

Version 3 breaks layout adjustments made in version 2, like tuplet and ornament placement, regardless of whether auto-adjust is applied or not. New versions make files un-openable in previous versions. That's normal. It's also certainly possible for old algorithms to get called when an old file is opened, and they don't have to be "maintained"; they just sit there, but it depends what the team's mindset is there. I still see no valid argument for not fixing this problem, other than low priority, which is understandable but not convincing given that the problem has been known for many years and takes a lot of time to manually fix.

Why not just fix this problem now? Add auto dot-tie clash correction to the auto layout option for opening old files. Just make the algorithm so it doesn't adjust a tie if the user has already adjusted it. I don't see a problem.

Please re-read my previous response carefully. We can't detect that a score is "old" without changing the file format version and thus making it impossible for older versions to open newer scores. And you can't maintain two separate layut algorithms for each and every change you make indefinitely - it's just not sustainable.

You don't make an enormous change like that just to fix one glitch in tie layout in a minority of cases. As I said, we make that choice going from 2 to 3 which was a monumental release representing the culmination of years of effort and hundreds if not thousands of other incompatible changes that were all combined into one release to minimze the impact of such a decision. You simply can't just make a choice like that every time you fix a bug. It must be considered more carefully than that. Which is why changes like this are best saved for relatively major releases when they can be combined to minimize the pain.

This is not "one glitch in tie layout in a minority of cases". This is a very basic flaw that affects all normal scores having dotted tied notes in them.

Hi Marc,
The new algo can be same as old +small move only in case collision occurs.
That way you don't need to care about file version at all and it will be perfectly compatible with already manually fixed scores.

When I say a minority of cases, consider, it's not all dotted tied notes, it's only dotted tied notes in the presence of either multiple voices, chords, or some other combination of factors. Yes, I realize that in certain contexts, this happens a lot. But the mere fact you don't see dozens of "me toos" on this (whereas there were for many, many other things we spend the last several years working on) is significant.

Again, I'm not saying it isn't worth fixing. Just that the sort of calamity that ensues from breaking compatibility is not something a responsible software developer inflicts on users on every minor release. I'm simply saying, these things need to be handled carefully. Please respect that.

@frfancha what you suggest reasonable on the surface but it's not how layout works. First a default position is calculated, then manual adjustments are calculated from it. If the default changes, then previously applied manual adjustments will be problematic. And here, it's the fact that this isn't exactly a rare case that makes it dangerous to change this in a minor release, because it would mean a lot of pain for anyone who had spent hours carefully adjusting ties.

@Marc,
Yes I understand the way positioning currently works and the challenge it causes with scores having manual adjustments.
And this is why I propose another approach.
Think about it: as you say yourself it is almost impossible, with the current approach, to improve any defaut positioning without breaking all past scores with manual adjustments.
It means that there is a big flaw in the design.

P.S. Marc, what frfancha said is the same what I already said above "Just make the algorithm so it doesn't adjust a tie if the user has already adjusted it".

The lack of "me too" here may be that hobby users probably don't care about this, but those of us who publish music do care.

Again, it's not that we're "adjusting" the tie. That would imply there was some original position and now we're changing it. No, we're calculating the original position from which manual adjustments are applied. If we calculated two different default positions depending on whether manual adjustments were applied, you'd have ties jumping out from under as you tried to adjsut them. I actually do know a thing or two about how layout works :-)

As for people who publish music, we have made many improvements specifically for that. This just didn't happen to make the cut at the last window of opportunity because other matters were higher priority even for that set of users.

Can we please just accept that this will get dealt with in due order?

Marc said: "we're calculating the original position from which manual adjustments are applied."

That's the problem, and we're both saying: don't do this that way.

Marc said: "If we calculated two different default positions depending on whether manual adjustments were applied, you'd have ties jumping out from under as you tried to adjsut them."

Nobody suggested creating two defaults. Instead of changing the default, add a postfix for the clash, only in cases where the position has not been altered from the default. That is what 2 people have tried to explain now. You could even make it non-automatic, a menu option. Select it to fix the clashes. Not optimal but it would be nice to have until the "real" layout change can be made.

OK, obviously you understand how the code works better than I. Looking forward to your PR!

I'm sure you have a deep understanding of how MuseScore layout works. Nobody has challenged that. The suggestion made above is perfectly reasonable, and doesn't require changing the way the layout works. It's a post fix idea as a stop-gap until a "real" fix can happen.

I already explained the reasons I believe this would be problematic, but maybe you are seeing something I am not, so I say, if you believe you can solve the problems I identified, have at it! I'm serious. I got started by fixing something that bothered me that no one else was dealing with - and actually, it was about ties (making sure they aren't too short in tightly-spaced settings).

This is kind of funny to me. At a rehearsal tonight, here is a chart brought in by one of the musicians, this was the default output from Sibelius:

In one of those really "small world" coincidences, one of the other players works for Finale, another used to be a professional music engraver (pre-software).

Here's another idea I think would solve all the difficulties:

Make it a style option, like shortened stems. This would allow implementing the "real" fix in the layout. The switch would allow old manually-fixed scores to work, and it would correct new scores. Leave the switch off by default.

(P.S. In the Sibelius image it looks like maybe they failed to make their dot-tie clash correction font-aware. the jazz font, which has thicker lines, requires looser spacing. Only the tie on the A to the right is really obviously clashing with a dot. The other ties look like they are being repositioned according to a non-jazz font.)

I think we need a more general solution to the issue that could cause changes in layout in general, even if that specific case can be fixed as you say.
I'll open a new thread for that.

@frfancha, I don't follow. The proposed solution is a general one. It would do the following:

1. will fix this problem as a true layout algorithm, using a style option, the same way stem-shortening is handled
2. is backward compatible, because the switch can be off by default
3. doesn't require a different file format version

What more do you want?

Style settings are not without merit here - there could be a way to control whether the ties start to the right of the dot or above/below, and by how much, for instance. Finale apparently provides something like this. But an issue with is that you can't enable the option by default, or it will apply to old scores. So it ends up being more work to implement something that only helps the select few who discover the option. Style settings make the most sense when you can make the default reasonable but there is also a legitimate use case for deviating from the default. And as far as it being a general solution, you can't really do this to solve each and every problem, you end up a confusing mess of style settings you need to go in and tweak to get the results you should be getting by default.

So again, the bottom line for me is, it is important to proceed carefully and to really consider the bigger picture. There are quite a few other layout issues I think should all be handled together so they can be handled right, and we can choose to accept with whatever incompatibility results, whether it's "older scores look different" or "older versions can't open newer scores". A productive thing that could be done at this point is to go through the issue tracker and collect all such issues in one place, like by adding them to a new "EPIC" issue for proposed 3.x layout improvements that would affect compatibility.

(accidental double post)

Oh, what was meant by "general solution" and "specific case" wasn't clear before. Now it's clear.

In my opinion, it is not possible to avoid all of them.
Dots, ties, slurs, accidentals and finger-numbers will surely overlaps in some places.
In the final stage, it will be necessary to check and correct some things.

In any case, a correction that prevents all conflicts and meets the wishes of all users is not possible.
One will say "tie is too high here", the other will say "tie has gone too far from the note", another says, "this dot has too low.", etc.

Any news with an augmentation-tie avoidance algorithm? . . .

I am not aware of you or anyone else starting the process I described of going through the issue tracker looking for other layout issues to try to consider together. See again https://musescore.org/en/node/45576#comment-937391

Thanks for the reply. Sounds like it's not yet planned to be under development.

Again in https://musescore.org/en/node/305592

It would be useful at least to have the possibility to say MuseScore to begin ties after the propongation dot, as for instance in Finale.

Not to make anyone feel any pressure, but is there any possibility that a fix to some of these tie issues could be included with version 4? I wish I could get involved in the development, and indeed hope to in the future, possibly, but I am useless with programming at this point.

Re: Stefano Rattini - The standard practise is to keep the ends of the tie where they are horizontally, and move the tie out of the way of the dot vertically either up or down depending on the orientations of the tie and the dot. There are some situations where starting the tie after the dot is the only option which avoids collisions, but that should be used as a last resort only when vertical displacement produces some other collision.

Relates to #311175: [EPIC] Engraving issues and suggestions

Tie collision with dotted note on a line still present in version 3.6.0.487915347 Rev 1977cb3 MacOS

Indeed, that is why this issue is still active.

See also https://github.com/musescore/MuseScore/issues/8980

See also https://github.com/musescore/MuseScore/issues/9005

I just took a quick look at the MuseScore 4 nightly build, and I just gotta say is thrilling to see this issue being addressed! :) :) :)

Automatically closed -- issue fixed for 2 weeks with no activity.

I've just seen this has apparently been addressed in MS4, which is great news, but could someone please tell us how this has been addressed? I'm concerned because as I mentioned before, in almost all cases, it looks better to move the ties vertically and not to move the endpoints horizontally (Finale and other software gets that wrong). How has the tie/dot clash correction been implemented in MS4? Thank you.

See the above links to the PRs

Thanks, now I see at https://github.com/musescore/MuseScore/issues/8980 , the fix is an adjustment of the tie ends, to make them start after the dot, which is the wrong solution as I just mentioned above. So, could this issue be opened again please? Thank you.

No, open a new one, preferably on github. Or comment on that github issue

It seems there is some authority that one solution to avoid tie/dot clashes is to shorten ties to avoid dots as cited much earlier in this thread. See https://musescore.org/en/node/45576#comment-405401. Gould also suggests starting ties after a dot as a possible solution. "Position ties so no dot is obscured. Ties may start immediately after each notehead, in between the duration dots as longs as they will fit without colliding [...] Otherwise inner ties should start after the dots.".

I guess there may be other authorities that suggest an alternative approach but at least a solution with some formal justification has been implemented in MS4.

That make 2 authorities. Add @oktophonie (he aproved that change and prior to MuseScore worked as an engraver at a Boosey & Hawkes, a major publisher) and you have 3

Besides the authorities, tie ends totally may not be moved vertically because they’d be more easily confused wiht slurs if the slope changes.

Sorry, no. That argument is just silly. Moving a tie vertically does not change its slope (it's always the same, 100% horizontal). There is no confusion with slurs. Please go look at some printed scores and see how often the ties are quite far away from the note heads.

Starting the tie after the dot is better than nothing, but it does not look better than moving the tie vertically, despite all this repetition of the opposing view. More importantly it will not work in all use cases (think short horizontal space).

I'd agree that in some cases at least, moving vertically might work. It's likely to be problematic if the chord has closely-spaced notes and there are also markings that might then also be moved. Depending on the shape of the chord and length of tie, it might also be necessary to increase the curvature, which is done in some editions but doesn't look particularly good to me and would be very difficult to implement (and time-consuming to execute). Simply moving the start point should always be safe, because the layout algorithms can easily add space as necessary. I suspect that's why Gould mentions both options - keep the tie close to the notehead if you can find a way to do it, but move it after the dot as the fall-back.

Anyhow, someday indeed as a further enhancement, an algorithm could possibly be designed that attempts a vertical and/or curvature adjustment, but it would be quite a bit more complex.