It's a tricky case. Probably it should look something like the image attached (created in LilyPond). More research needs to be done to work out all the edge cases for tied seconds. I known that ties should avoid collisions with note heads or note flags when possible but I'm not sure I could tell a computer the rules for where to place the tie instead.
LilyPond seems to get this case right, but Finale 2012 makes the same mistakes that MuseScore is making.
P.S. Xavierjazz, you probably already know this, but you can double click on a tie and fix it manually.
No - this is not a problem in Finale or Sibelius, and it has an easy fix!
I know how to fix this - logically.
I have been bothered by this problem lately.
The problem here is the logic in the endpoint of the ties.
Given: Note 1 is tied to Note 2.
The endpoint seems to be the beginning of Note 2 (central left).
This works fine for a single note tied to another. However, it breaks down if Note 2 is part of a chord.
The logic should be:
If Note 2 is alone --> current behavior.
If Note 2 is part of a chord -->
Make the endpoint the same height as current behavior (Y position), but align to the central left of the leftmost notehead in the chord (X position).
Make sense? I don't know the code well, since I'm new to this particular project, but that would be quite possible assuming your object hierarchy allows you to trace through the properties of each individual note in a given chord AND tell if a note is part of a chord. I'd assume it can.
Also - to add more logic -- I noticed the same problem if Note 1 belongs to a chord.
So, if Note 1 belongs to a chord, the tie should START at the center (Y) rightmost edge (x) of the notehead.
I hope this gets fixed - it would save many hours of manual tie-fixing on my scores!
Yes, accounting for dots or double dots, or even the rare triple dot should be done.
So, that should be an absolute shift scaled based upon the size of the notehead.
So, after the above logical changes are made, there can be a final pass where we check to see if the note being tied from or tied to is dotted and shift accordingly.
So, how do code changes get made?
FYI, I have experience with Java and C++. I am also a composer and music instructor, and a long-time Sibelius and Finale user (finally ditching them). However, I am new to this forum, and open-source projects in general.
In my view, Sibelius 7 has it correct. That is the best, and most easily-readable way to print the ties in this scenario. It also avoids collisions gracefully.
Here's some examples from books by International Music Publications - transcribed by Barnes Music Engraving, who apparently used Amadeus (according to an interview
with them).
Behind Bars recommends, "It is usually clearer to start each tie close to each notehead, rather than to align all ties after all notes" (p. 63). Alfred's Essential Dictionary of Music Notation makes a similar recommendation. So while Sibelius' option is certainly the easiest to code, it isn't optimal. That said, it is better than ties overlapping with noteheads so I wouldn't be opposed to this being implemented for now. (Although fixing this would likely bring up the following bug for this situation: http://musescore.org/en/node/2316 )
Lilypond's output looks fine to me. If there were more space between the notes (e.g. a tie over the barline) then the middle tie could probably pop down a space and start after the notehead instead of above.
"The ties in the middle should curve up if they are above the middle line, or curve down if they are on/below the middle line"
That contradicts with the example here - the middle tie should be down, but is up? Maybe it shouldn't matter, as ties should still be in the correct position and not collide?
I think you'll find different editors have different standards here, but in the list David posted in the issue you referenced, note the last item says that ties for seconds should be in opposite directions. That trumps the rule about the middle line.
It seems to me, judging from the examples posted by Chen Lung, that human engravers would have shifted the top F to align it with the D, in order to avoid the collision. None of the programs cited does this, which suggests they all follow the same faulty logic (and that Musescore could do better than all of them...!).
I'm sorry to revive this old issue, but I've just faced it myself.
This is what I came up with, mirroring the notes A and B on the tied chord so that B would stay closer to the tied note than A.
original.png is how Musescore originally wrote the notes, mirrored.png is how it looks after the mirroring. Is this somehow acceptable?
Comments
It's a tricky case. Probably it should look something like the image attached (created in LilyPond). More research needs to be done to work out all the edge cases for tied seconds. I known that ties should avoid collisions with note heads or note flags when possible but I'm not sure I could tell a computer the rules for where to place the tie instead.
LilyPond seems to get this case right, but Finale 2012 makes the same mistakes that MuseScore is making.
P.S. Xavierjazz, you probably already know this, but you can double click on a tie and fix it manually.
IMHO no extra info mis needed :)
No - this is not a problem in Finale or Sibelius, and it has an easy fix!
I know how to fix this - logically.
I have been bothered by this problem lately.
The problem here is the logic in the endpoint of the ties.
Given: Note 1 is tied to Note 2.
The endpoint seems to be the beginning of Note 2 (central left).
This works fine for a single note tied to another. However, it breaks down if Note 2 is part of a chord.
The logic should be:
If Note 2 is alone --> current behavior.
If Note 2 is part of a chord -->
Make the endpoint the same height as current behavior (Y position), but align to the central left of the leftmost notehead in the chord (X position).
Make sense? I don't know the code well, since I'm new to this particular project, but that would be quite possible assuming your object hierarchy allows you to trace through the properties of each individual note in a given chord AND tell if a note is part of a chord. I'd assume it can.
Also - to add more logic -- I noticed the same problem if Note 1 belongs to a chord.
So, if Note 1 belongs to a chord, the tie should START at the center (Y) rightmost edge (x) of the notehead.
I hope this gets fixed - it would save many hours of manual tie-fixing on my scores!
Welcome :)
Also see this .
Yes, accounting for dots or double dots, or even the rare triple dot should be done.
So, that should be an absolute shift scaled based upon the size of the notehead.
So, after the above logical changes are made, there can be a final pass where we check to see if the note being tied from or tied to is dotted and shift accordingly.
So, how do code changes get made?
FYI, I have experience with Java and C++. I am also a composer and music instructor, and a long-time Sibelius and Finale user (finally ditching them). However, I am new to this forum, and open-source projects in general.
Summary
![finale2009.png]( "finale2009.png")
Finale 2009
Sibelius 7
![Sibelius7.png]( "Sibelius7.png")
Lilypond
MuseScore 1.2 (same in MuseScore cf850d8d48)
None of them looks right to me... Can any one locate an old edition from a respected publisher with this note configuration?
@CompleteMusician It's probably not the good place to teach you how to deal with the source code. You coul join the Tech Preview forum, the developer mailing list or the IRC channel #musescore on freenode.net.
In short, instructions to build the current git is here : http://musescore.org/en/developers-handbook/compilation
Our Git Workflow : http://musescore.org/en/developers-handbook/git-workflow
Tie layout code is in slur.cpp
Keep in mind that a tie can be cut in segment if at end of system and that tie direction is set automatically. A fix for this bug should probably be linked with a MSCZ files and different test cases.
In my view, Sibelius 7 has it correct. That is the best, and most easily-readable way to print the ties in this scenario. It also avoids collisions gracefully.
Here's some examples from books by International Music Publications - transcribed by Barnes Music Engraving, who apparently used Amadeus (according to an interview with them).
I hope it helps.
Behind Bars recommends, "It is usually clearer to start each tie close to each notehead, rather than to align all ties after all notes" (p. 63). Alfred's Essential Dictionary of Music Notation makes a similar recommendation. So while Sibelius' option is certainly the easiest to code, it isn't optimal. That said, it is better than ties overlapping with noteheads so I wouldn't be opposed to this being implemented for now. (Although fixing this would likely bring up the following bug for this situation: http://musescore.org/en/node/2316 )
Lilypond's output looks fine to me. If there were more space between the notes (e.g. a tie over the barline) then the middle tie could probably pop down a space and start after the notehead instead of above.
I wondered if it also depended on the spacing between the notes, but neglected to ask.
I'm looking at this: #13034: Tie direction for chords
"The ties in the middle should curve up if they are above the middle line, or curve down if they are on/below the middle line"
That contradicts with the example here - the middle tie should be down, but is up? Maybe it shouldn't matter, as ties should still be in the correct position and not collide?
I think you'll find different editors have different standards here, but in the list David posted in the issue you referenced, note the last item says that ties for seconds should be in opposite directions. That trumps the rule about the middle line.
It seems to me, judging from the examples posted by Chen Lung, that human engravers would have shifted the top F to align it with the D, in order to avoid the collision. None of the programs cited does this, which suggests they all follow the same faulty logic (and that Musescore could do better than all of them...!).
(Never mind)
Here's a score to try.
Sibelius in #8 is the best way to my eye.
Still the case in MS 2.3.
I'm sorry to revive this old issue, but I've just faced it myself.
This is what I came up with, mirroring the notes A and B on the tied chord so that B would stay closer to the tied note than A.
original.png is how Musescore originally wrote the notes, mirrored.png is how it looks after the mirroring. Is this somehow acceptable?
Clever, but not recommended. Better to adjust the ties. FWIW, this is solved for MuseScore 4 - the defaults should be much better.
Let's mark it fixed in 4.0 then
Automatically closed -- issue fixed for 2 weeks with no activity.