Menu

#2249 ledger lines of pitched rests are verticaly misplaced

Accepted
nobody
None
evidence
Enhancement
2014-06-01
2012-01-24
Anonymous
No

Originally created by: *anonymous

Originally created by: Elu...@gmail.com

the code below shows ledger lines for pitched rests which are not aligned with the ledger lines of notes:

\paper { indent = 0 }
\language nederlands
mus = \relative c {
  d2 d \rest
  e e \rest f f \rest g g \rest a a \rest b b \rest c c \rest d d\rest e e \rest
  e e \rest f f \rest g g \rest a a \rest b b \rest c c \rest d d\rest e e \rest
  e e \rest f f \rest g g \rest a a \rest b b \rest c c \rest d d\rest e e \rest
}
<<
  \mus
  \context NoteNames { \mus }
>>
\version "2.15.26"

1 Attachments

Discussion

  • Google Importer

    Google Importer - 2012-01-24

    Originally posted by: m...@mikesolomon.org

    Are you sure this is a bug?
    By definition, the pitched rest will be put at the same latitude as the corresponding note.  This means that, for notes that fall in spaces, the pitched rests' ledger lines won't line up with those of a note.

    Or is there something more subtle going on in the image that I'm not seeing?

    To mark it as critical, it needs to be a regression or heinously ugly.  If it's the latter, could you (or the original reporter) upload a PNG of the good behavior from a previous version of LilyPond?

     
  • Google Importer

    Google Importer - 2012-01-24

    Originally posted by: benko....@gmail.com

    I think the bug is that (though the rests are really at the required height) ledger lines are not aligned to the staff, but to the rest.
    I also think that e2\rest would not occur in real code, at least I don't know what a user writing that would expect.

    (I wanted to refer to my usage of pitched rests in the LilyPond wiki, but it's unavailable; the point is that I either write pitches know to be good, or apply a function that moves rests to a good position - this is a must when I want a piece of music it different transpositions.)

     
  • Google Importer

    Google Importer - 2012-01-25

    Originally posted by: m...@mikesolomon.org

    The ledger line is part of the glyph ("rests.1o").  Do you want the line to go through the rest?  I don't recall ever having seen this in the literature, so it's tough for me to imagine what one would want.  What would help are either examples from the literature or ly code that, by means of various kludges, produces the desired result.

     
  • Google Importer

    Google Importer - 2012-01-25

    Originally posted by: benko....@gmail.com

    > The ledger line is part of the glyph ("rests.1o").

    aargh, I haven't checked.  What's more, I even missed that intermediate ledger lines are missing - now that's really a bug!  I think ledger lines should be drawn just like for note heads; I'll try to find some time in the near future to look into that.

     
  • Google Importer

    Google Importer - 2012-01-25

    Originally posted by: mts...@gmail.com

    I don't think this should block a stable release, so I'm downgrading to ugly and waiting on Pal's evidence.

    Labels: -Type-Critical Type-Ugly Needs-evidence

     
  • Google Importer

    Google Importer - 2012-01-25

    Originally posted by: janek.li...@gmail.com

    Unfortunately i don't know what the situation was before Pal's fix (issue 2109 description doesn't say anything), but i think we should revert this patch.

     

    Related

    Issues: #2109

  • Google Importer

    Google Importer - 2012-01-25

    Originally posted by: benko....@gmail.com

    > i don't know what the situation was before Pal's fix

    off my head: the rest was moved (together with the single ledger line) up; extra ledger lines (between staff and rest grob) were not drawn.
    in case of nonstandard staves this made for _all_ rests appearing in wrong position.
    the point in my fix was that *if* the user explicitly asks for a position, then LilyPond shouldn't overrule.

    I see the issue at hand totally unrelated to issue 2109; in fact there are two separate issues:
    1. not enough ledger lines
    2. ledger line not aligned to staff

    however, this may actually be the required behaviour for a staff with two voices, the lower going above the staff while the upper takes a rest.

    > i think we should revert this patch.

    not too quickly, please.  I'd like to see that without my patch the original problem goes away.
    my patch seems small, but it fixed an actual problem of mine that I couldn't work around in my .ly sources.
    (I may add that when my files broke I found the patch that caused the regression, but saw that it was good, just exposed a bug.)

     

    Related

    Issues: #2109

  • Google Importer

    Google Importer - 2012-01-25

    Originally posted by: Elu...@gmail.com

    after compiling with a higher resolution (660) and looking for examples in the literature  - so quickly I could only find one example - I must agree in every point!

    btw - I don't think more ledger lines should be added to a half or a full (or any) rest - the ledger line probably is just a help to make the distinction.

    sorry for the noise, I'll mark the issue as invalid! if new question arise a new issue should be opened.

    Eluze

    Status: Invalid

     
  • Google Importer

    Google Importer - 2012-01-26

    Originally posted by: PhilEHol...@googlemail.com

    It seems to me this is a valid bug report - the rests should have ledger lines if they're pictched away from the stave - but it seems "old" behavior.  2.12.3 example attached.

    Status: Accepted

     
  • Google Importer

    Google Importer - 2012-01-26

    Originally posted by: Elu...@gmail.com

    yes, but in my first post I was thinking that the ledger line of the rests outside of a staff should be aligned with the notes' ledger lines and I have been convinced this is not correct.

    the real bug seems that when you are using pitched rests inside the staff you cannot distinguish half and full rests!

    outside of the staff these rests get a ledger line (which is part of the glyph, as has been mentioned above) and for me it doesn't matter if they are 1 mm lower or higher.

    do you agree with this and shall I open a new issue or would you prefer this to be carried on?

    maybe I didn't catch what you mean?

     
  • Google Importer

    Google Importer - 2012-01-26

    Originally posted by: k-ohara5...@oco.net

    Ross (p174) says that when you need to put a whole rest outside the staff, you should find a convenient place and draw the rest below a ledger line (in the singular).  His example places this ledger line at a height that would fall halfway between the ledgers we use for notes. LilyPond is doing fine on this point.

    > the real bug seems that when you are using pitched rests inside the staff
    > you cannot distinguish half and full rests!

    One must pitch half and whole rests to a note that sits on a line, not in a space.
    If you do so, then half and whole rests are distinguished; if you do not, the rest looks strangely-placed, and not quite like a rest of the other duration.

    Labels: -Type-Ugly Type-Enhancement
    Status: Invalid

     
  • Google Importer

    Google Importer - 2012-01-27

    Originally posted by: Elu...@gmail.com

    "... and not quite like a rest of the other duration." - what does that mean?

    thanks for the research, so LilyPonds behavior is correct in general.

    conclusion: if somebody uses pitched rests it's his responsibility to put them at the correct height - special attention is needed when using half or whole rests.

     
  • Google Importer

    Google Importer - 2012-08-31

    Originally posted by: dak@gnu.org

    Arguably, one might want LilyPond to help with line-based placement when transposition comes into play.  Better not think too much about that.

     
  • Google Importer

    Google Importer - 2012-08-31

    Originally posted by: benko....@gmail.com

    I can post my function mentioned in comment 2.  currently it assumes normal spacing, but expanding it to handle abnormally spaced staves can't be too difficult.

     
  • Google Importer

    Google Importer - 2012-08-31

    Originally posted by: dak@gnu.org

    I did not read your comment #2 previously.  Yes, doing it with a user function like you did seems like a sensible approach.  I would not really bother with further work unless there is some indication that anybody actually has come across the problem.

     
  • Google Importer

    Google Importer - 2014-06-01

    Originally posted by: PhilEHol...@googlemail.com

    Some further evidence.  Firstly, an image from LilyPond with double stemmed input.  The ledger line on the minim rest which sits between the other ledger lines looks plain weird to me.  This is the only case I have ever seen where ledger lines sit in the space of other ledger lines.  To be honest, I don't really care what the style guides say, I don't think this should happen.

    But anyway: to the style guides.  The example from comment 11 isn't described exactly: Keith says is sits halfway between ledgers.  Not quite: see the second image.  I'd describe it as randomly dropped on the page, and therefore not a great example to follow.

    Finally, Gould.  In text, she says "The rest moves up or down within the stave when a beam joins notes across a rest and in double-stemmed writing (see pp. 36-7). From the centre of the stave, rests move an exact number of stave-spaces up or down, so that they remain correctly positioned in relation to the stave-lines".  The example she gives is with rests in the stave, rather than outside, but I see no reason why the rule of moving exact numbers of stave spaces should be broken outside the stave.

    She also gives a snippet of music with rests outside the stave.  In this case she lines up ledger lines where the rest is near other music/ledgers, and fails to do so where the rests is a way outside the note (I realise this is counter to my argument: I'm being even-handed here.)

    My summary: where rests have ledger lines near other ledger lines, they must line up.  The most appropriate way to do this is to ensure that rests always move by integral stave spaces, even outside the stave.

    Status: Accepted

     
  • Google Importer

    Google Importer - 2014-06-01

    Originally posted by: benko....@gmail.com

    this is what I use currently to fix rest pitches.
    to add some context: in ancient notation it is customary to place rests near to the preceding or succeeding note - this actually helps understanding the meter.  that means that I must consider the duration of the rest and the place of the aligning note (whether it's on a line or in a space).  care should be taken with whole rests as pitching a whole rest on a line means the rest will hang from the next line!

    ------------------------------------------------------------->8
    % move a rest half a space down if not on a line (needed when transposing)
    #(define (round-pitch p)
      (let* (
        (o (ly:pitch-octave p))
        (n (ly:pitch-notename p))
        (m (* (floor (/ (+ (* 7 o) n) 2)) 2))
        (a (remainder m 7))
        (b (/ (- m a) 7))
      )
       (ly:make-pitch b a 0)))

    #(define (fix-rests music)
      (let (
        (n (ly:music-property music 'name))
        (p (ly:music-property music 'pitch))
      )
       (if (and (ly:pitch? p) (eqv? n 'RestEvent))
        (ly:music-set-property! music 'pitch (round-pitch p)))
       music))

    fixRests =
    #(define-music-function (parser location mus) (ly:music?)
      (music-map (lambda (x) (fix-rests x)) mus))

    % in this example all rests are aligned to the previous note
    mus = { g'2 g'\rest f'1\rest g'\breve\rest a'2 a'\rest g'1\rest a'\breve\rest }

    \fixRests
    {
      \cadenzaOn
      \mus \transpose g a \mus
    }

     
Auth0 Logo