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? 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. Cheers /Leo > 17 okt. 2019 kl. 00:24 skrev Thomas Morley <thomasmorle...@gmail.com>: > > Am Mo., 14. Okt. 2019 um 12:22 Uhr schrieb Leo Correia de Verdier > <leo.correia.de.verd...@gmail.com>: > >> When you write that "inner beams positions can’t be affected from >> Glissando.after-line-breaking", do you mean it’s impossible, that they would >> need to be recreated rather than repositioned or just that the actual code >> can’t handle them yet? > > The code recreates Stems (and moves Script), but it can't _move_ Beams. > It would likely be possible to completely recreate Beam.stencil, > though this is inconveniant and would add a lot code... > > Currently, this means my code sometimes returns ugly output for Beams, > which will need to be corrected with an additional override for > Beam.positions. > > > Cheer, > Harm _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user