Am Sa., 19. Okt. 2019 um 00:01 Uhr schrieb Leo Correia de Verdier
<leo.correia.de.verd...@gmail.com>:
>
> Thanks a lot for your help!
>
> Quite to my surprise I found the following snippet does work.
>
> %%%%%%%%
>
> \version "2.19.82"
>
> #(define changebeam (lambda (grob)
> (let* ((stem (ly:grob-object grob 'stem))
> (beam (ly:grob-object stem 'beam)))
> (ly:grob-set-property! beam 'positions '(-4 . 5))
> )))
>
> {\once \override NoteColumn.after-line-breaking = #changebeam
> c8 d8 r2.}
>
> %%%%%%%%
>
> Unfortunately I couldn’t get changing the beams ’position property to work in
> the context of the larger function. Do you understand why?
The point is not a large function, but which grob is tackled at which
time-step of compilation.
>
> Otherwise, the starting-point I see for recreating beams is drawing them from
> the stem’s beaming-property (querying other properties for thickness, spacing
> and slope damping). I think I could achieve that, but would like to know if
> someone sees a better option.
>
> On a sidetone from that: How does the (beam slope) damping factor affect the
> beam calculation? I can see and understand its effect, but wonder what the
> calculation behind it is.
Meanwhile I've probably found a method to affect Beams from inside a
Glissando.after-line-breaking, but currently it's not mature to say
more.
Anyway, my goal will be to make Beams parallel to the glissando-line,
I don't think doing differnt makes any sense. So I don't care much
about damping, etc. At least currently.
I may be convinced, though. Do you see use-cases for Beams not
parallel to Glissando?
Cheers,
Harm
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
