[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug? getting the stencil of the stem removes the beam

From: Thomas Morley
Subject: Re: Bug? getting the stencil of the stem removes the beam
Date: Thu, 15 Mar 2018 23:33:31 +0100

Hi Lucas,

all below under the condition 'if I understand correctly' ;)

2018-03-15 18:38 GMT+01:00 Lucas Werkmeister <address@hidden>:
> Hi everyone,
> I was trying to use the \displaceHeads function from snippet 861 [1] [2] on
> an eight-note chord, but found that it completely removes the beam for some
> reason.

Not exactly true.
The beam _is_ there: this very small line at the very right of the
resulting pdf (you've cut it off in your image)

> I reduced it down to the following code:
> \version "2.18.2"
> {
>   \tweak before-line-breaking #(lambda (grob)
>                                  (ly:grob-property (ly:grob-object grob
> 'stem) 'stencil))
>   c'8[ c']
> }

That I call a tiny example. I'd love to see more people doing so ;)

> You can find a screenshot of the result at [3]. The function here doesn’t
> mutate anything,

Not exactly. The stem-stencil _is_ evaluated!

> but apparently just accessing the stem is enough to render
> the associated beam invisible

Not just assessing but evaluating the stencil before-line-breaking and
the beam is there (see above)

> (at a guess, I’d say the beam’s stencil is
> being unset somehow – it still influences the layout otherwise). Is that a
> bug in LilyPond?

Not really.
The Beam needs to set it's related stem-stencils, if a user does it
'before-line-breaking as the lsr-snippet does, the procedure setting
the beam is disturbed.

So far the lsr-snippet is bad.
Though, in my humble opinion LilyPond should print a meaningful message...

> The \displaceHeads problem was previously reported at [4] (and I’ve added
> the author to CC for this email), but as far as I can see the thread didn’t
> go anywhere. (To answer the question in the reply [5] – changing
> before-line-breaking to after-line-breaking fixes the beam, but also removes
> the displacement effect, so as far as I can tell you might as well just get
> rid of the \displaceHeads completely.) I hope the reduced example above will
> help to get this bug (if it is one) fixed :)

Probably below will help.
I avoided any stencil-call (not sure whether calling 'direction will
turn out to be a problem, though)
The functions `setOtherScriptParent' and `adjustStem' from the
lsr-snippet would work, but are not used in the example.

\version "2.19.65"

#(define ((positioning-done move-values) grob)
;; TODO whole and longer notes are not special cased
;; probably exclude them form the procedure by uncommenting the condition
;  (if (< (ly:grob-property grob 'duration-log) 1)
;      #f
      (let* ((nc (ly:grob-parent grob X))
               (ly:grob-extent grob nc X))
             (dir (ly:grob-property grob 'direction))
             (thick (ly:grob-property grob 'thickness))
               (if (interval-sane? grob-ext)
                   '(0 . 0)))
               (if (zero? (interval-length stem-ext))
                   (* -1 dir (interval-length stem-ext))))
               (ly:grob-object grob 'note-heads))
               (if (ly:grob-array? note-heads-array)
                   (ly:grob-array->list note-heads-array)

          (lambda (note-head v)
            (let* ((nh-ext (ly:grob-extent note-head nc X))
                   (nh-x-length (- (cdr nh-ext) (car nh-ext))))

              (* v (+ nh-x-length (* dir (/ stem-thick 2))))

chrd =
  \tweak color #green
  \tweak color #red
  \tweak color #blue

  \override NoteHead.layer = 500
  \accidentalStyle forget

    \tweak color #green
    \tweak color #red
    \tweak color #blue

  \bar "||"

  \once \override Stem.positioning-done =
      '(1 0 1)
      ;'(0 1 0)

  \once \override Stem.positioning-done =
      ;'(-1 0 -1)
      ;'(0 -1 0)
      '(-1 0 -1)

  \once \override Stem.positioning-done =
      ;'(-1 0 -1)
      ;'(0 -1 0)
      '(0 -0.668 0)
    \tweak color #green
    \tweak color #red
    \tweak color #blue

Not tested beyond the given examples, though.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]