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

• Jan 27, 2015 - 02:04
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

When a tie appears on the same side of a staff/ledger line as an augmentation dot, the tie goes right through the dot. In looking at professional engravings, the start point of the ties in this case are usually placed just above the dot if it is above the line, or just below the dot if it is below the line.

Here is a graphic comparing MuseScore's current behavior with ties adjusted similar to the engravings at my disposal:
tie and dot collision.png
The ties in question appear in measures 3, 7 and 11. For the ties in measures 3 and 7, I made the adjustment by moving the tie's start point up using 4 presses of the up arrow key. In measure 11, I moved it down 4 presses instead.

I have included the MuseScore file as well for your reference. I am using MuseScore nightly ff2b92c on Kubuntu 14.04 64-bit.

Attachment Size
tie and dot collision.png 38.92 KB
tie spacing.mscz 10.99 KB

Comments

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.

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

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:
tie_placement_1.png

After correction:
tie_placement_2.png

Severity S1 - Blocker
Reported version 2.1  
Priority P1 - High
Regression No
Workaround No

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.

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.

I have also found that it can be time consuming poring over a score to fix all of the impaled augmentation dots, particularly in scores using triple meter. Neither Finale, Sibelius or Dorico have this issue. At least a single CTRL-Right is enough to make the proper adjustment, which makes it not too painful for me.

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.

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.

In reply to by Marc Sabatella

@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.

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:

B7960154-679B-4151-9876-1DDCD1FF5289.jpeg

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.)

@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.

In reply to by Marc Sabatella

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.

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.

In reply to by Stefano Rattini

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.

Reproducibility Always
Reported version 3.6

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

In reply to by BarnieSnyman

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.

In reply to by Jojo-Schmitz

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.

In reply to by mirabilos

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.

Fix version
4.0.0