When a slur crosses a line break, the slur after the break begins
before the key signature. Phrasing slurs, on the other hand, begin
after the key signature. (This is not clear in any of the regression
tests because the slur examples are all in C major.)
How much work would it be to change ordinary slurs to begin after the key signature?
I believe that this would solve Issue 379 and Issue 427
I tried reading the slur code myself but I was totally lost.
I'm just looking for an estimate of the difficulty/likelihood of a fix
for starters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to Kurt Stone: ties and slurs (including phrasing slurs) at the
end of a line "should stop just before the clef" if there is one; otherwise,
"neither slurs nor ties should extend beyond the barline." Ties and slurs at
the beginning of a line should begin just after the time signature if there
is one; just after the key signature if there is no time signature; just
after the clef if there is neither key nor time signature.
Thus, in the following example, there are at least 6 errors with LilyPond's
rendering:
end of first line:
1. phrasing slur does not stop just before the clef
2. slur does not stop just before the clef
3. tie is so small, it looks like a dot
beginning of next line:
4. slur does not start just after the time signature
5. phrasing slur intersects slur
6. phrasing slur is unnaturally tall
And for my own 2 cents: it's my understanding that there should be a small
amount of space between the last of the front matter and the beginning of
the slurs/ties. In my example, the slurs/ties are all above the staff, so
this issue is less apparent. But when the slurs/ties are in the middle of
the staff, they usually touch the front matter with no space in between.
_________________________________________________
\version "2.11.62-1"
\paper {
indent=0
between-system-space=0
system-count=2
ragged-right=##t
}
\relative {
\slurUp \phrasingSlurUp \tieUp
\key f \major f\( e d( c~
\clef bass \key g \major \time 2/2 c b) a g\)
}
However, my approach was wrong, as Han-Wen noted, so I will need to start over.
Attached is what the image from comment 4 looks like with my old patch, just to give
an idea of what a solution to these bugs *might* look like.
The slur formatting doesn't look ideal, but I hope to eventually understand the code
well enough to make slurs behave well *and* look beautiful by default when they are
broken across line breaks.
Expect slur-line-break.ly and slur-multiple-linebreak.ly to show slurs stopping before the clef change, starting after key and time signature, at line breaks.
Patchy the autobot says: Contrary to announcement, the only changed regtest is slur-multiple-lineabreak.ly (and it is changed according to design). If the announcement for some reason was inaccurate, you may consider putting this to Patch-review yourself.
Labels: -Patch-new Patch-needs_work
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, the announcement forgot that 'slur-line-break.ly' is not in the test suite. It was a one of the new tests proposed in the patch in comment 8.
The image shows the patch's output for two of the cases from comment 8. LilyPond had been letting slurs continue past bar-lines that not quite at the end of the line. That is helpful for repeat bars, and I found the same in Edition Peters, so I let that continue.
The short tie in comment 4 is not solvable in the same way as the slurs were. There is not enough space allowed for the tie in the note-spacing step. I'll open a new issue for that.
The slur slope noted in comment 11 is also a different set of design choices. LilyPond tries to make each half of the broken slur fit the notes under each broken half. The melody line goes down just before the line-break, so the slur goes down.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally posted by: v.villenave
Comment from Andrew:
http://lists.gnu.org/archive/html/bug-lilypond/2008-05/msg00097.html
When a slur crosses a line break, the slur after the break begins
before the key signature. Phrasing slurs, on the other hand, begin
after the key signature. (This is not clear in any of the regression
tests because the slur examples are all in C major.)
How much work would it be to change ordinary slurs to begin after the key signature?
I believe that this would solve Issue 379 and Issue 427
I tried reading the slur code myself but I was totally lost.
I'm just looking for an estimate of the difficulty/likelihood of a fix
for starters.
Originally posted by: v.villenave
... And Andrew even offered a $50 CDN bounty for these two bugs.
http://lists.gnu.org/archive/html/bug-lilypond/2008-10/msg00098.html
Labels: Bounty
Originally posted by: csnyd...@mvpsoft.com
I'll chip in $50 USD to see these two bugs fixed.
Originally posted by: v.villenave
New comment from Mark Polesky:
According to Kurt Stone: ties and slurs (including phrasing slurs) at the
end of a line "should stop just before the clef" if there is one; otherwise,
"neither slurs nor ties should extend beyond the barline." Ties and slurs at
the beginning of a line should begin just after the time signature if there
is one; just after the key signature if there is no time signature; just
after the clef if there is neither key nor time signature.
Thus, in the following example, there are at least 6 errors with LilyPond's
rendering:
end of first line:
1. phrasing slur does not stop just before the clef
2. slur does not stop just before the clef
3. tie is so small, it looks like a dot
beginning of next line:
4. slur does not start just after the time signature
5. phrasing slur intersects slur
6. phrasing slur is unnaturally tall
And for my own 2 cents: it's my understanding that there should be a small
amount of space between the last of the front matter and the beginning of
the slurs/ties. In my example, the slurs/ties are all above the staff, so
this issue is less apparent. But when the slurs/ties are in the middle of
the staff, they usually touch the front matter with no space in between.
_________________________________________________
\version "2.11.62-1"
\paper {
indent=0
between-system-space=0
system-count=2
ragged-right=##t
}
\relative {
\slurUp \phrasingSlurUp \tieUp
\key f \major f\( e d( c~
\clef bass \key g \major \time 2/2 c b) a g\)
}
Originally posted by: pnorcks@gmail.com
(No comment was entered for this change.)
Status: Started
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Labels: -Priority-Low Priority-Medium
Owner: percival.music.ca
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Owner: pnorcks
Originally posted by: pnorcks@gmail.com
I will start working on this issue and issue 427 very soon.
My original patch is still posted here: http://codereview.appspot.com/109071/show
However, my approach was wrong, as Han-Wen noted, so I will need to start over.
Attached is what the image from comment 4 looks like with my old patch, just to give
an idea of what a solution to these bugs *might* look like.
The slur formatting doesn't look ideal, but I hope to eventually understand the code
well enough to make slurs behave well *and* look beautiful by default when they are
broken across line breaks.
Labels: -Engraving-nitpick
Originally posted by: pnorcks@gmail.com
I'm no longer working on this issue. Also, see Issue 427.
Here's the patch, in case someone wants to have a look:
http://codereview.appspot.com/109071
Owner: ---
Status: Accepted
Originally posted by: percival.music.ca@gmail.com
(No comment was entered for this change.)
Labels: Patch-abandoned
Originally posted by: PhilEHol...@googlemail.com
Here's another example of a slur - in this case, it's really going the wrong way on the upper system:
\version "2.14.1"
\paper{ ragged-right=##t }
\relative c' {
\clef bass
d4 d d( r \break d')
}
Originally posted by: k-ohara5...@oco.net
If we short-indent = 20\mm Mark's example, it becomes clear that the phrasing slur is based at the paper edge.
Originally posted by: k-ohara5...@oco.net
Expect slur-line-break.ly and slur-multiple-linebreak.ly to show slurs stopping before the clef change, starting after key and time signature, at line breaks.
<http://codereview.appspot.com/6294079/>
Originally posted by: dak@gnu.org
Patchy the autobot says: Contrary to announcement, the only changed regtest is slur-multiple-lineabreak.ly (and it is changed according to design). If the announcement for some reason was inaccurate, you may consider putting this to Patch-review yourself.
Labels: -Patch-new Patch-needs_work
Originally posted by: k-ohara5...@oco.net
Oops, the announcement forgot that 'slur-line-break.ly' is not in the test suite. It was a one of the new tests proposed in the patch in comment 8.
The image shows the patch's output for two of the cases from comment 8. LilyPond had been letting slurs continue past bar-lines that not quite at the end of the line. That is helpful for repeat bars, and I found the same in Edition Peters, so I let that continue.
Labels: -Patch-needs_work Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Owner: k-ohara5...@oco.net
Originally posted by: ColinPKC...@gmail.com
Counted down to 20120619, please push.
Labels: -Patch-countdown Patch-push
Originally posted by: k-ohara5...@oco.net
commit [r16a328617e867892e8d5608f95bd6127196e03a2]
Labels: -Patch-push fixed_2_15_41
Status: Fixed
Originally posted by: k-ohara5...@oco.net
The short tie in comment 4 is not solvable in the same way as the slurs were. There is not enough space allowed for the tie in the note-spacing step. I'll open a new issue for that.
The slur slope noted in comment 11 is also a different set of design choices. LilyPond tries to make each half of the broken slur fit the notes under each broken half. The melody line goes down just before the line-break, so the slur goes down.
Originally posted by: ma...@gregoriana.sk
(No comment was entered for this change.)
Status: Verified