lilypond-user
[Top][All Lists]
Advanced

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

Re: Tweaking glissando timing stems


From: Leo Correia de Verdier
Subject: Re: Tweaking glissando timing stems
Date: Sun, 20 Oct 2019 00:30:23 +0200

> 19 okt. 2019 kl. 12:36 skrev Thomas Morley <address@hidden>:
> 
> Am Sa., 19. Okt. 2019 um 00:01 Uhr schrieb Leo Correia de Verdier
> <address@hidden>:
>> 
>> 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.

I see (at least partially). While I never thought the behavior was affected by 
the size of the function I thought they would behave the same since both were 
processed after line breaking, but of course different grobs will be processed 
at different times then too.

>> 
>> 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?

I don’t think it’s very crucial, but in the case of steeper glissandos I can 
see the use for less steep beams, just because they would look better and match 
the behavior of beams in other places, especially in shorter beamed groups. 
This can serve as example (I prefer the look of the second bar):

%%%
\version "2.19.82"
glissNote = #(define-music-function (up y-diff note) (boolean? number? 
ly:music?)
               #{ \tweak transparent ##t
                  \tweak no-ledgers ##t
                  \tweak stem-attachment #(cons (if up -1 1) y-diff)
                  #note #} )

glissSkip = #(define-music-function (music) (ly:music?)
               #{ \override NoteColumn.glissando-skip = ##t
                  #music
                  \revert NoteColumn.glissando-skip #} )
\relative {
  \override Beam.damping = #0
  c'''4 \glissando \glissSkip {\glissNote ##f 0.8 f,16-- \glissNote ##f 0.5  
c8-- \glissNote ##f 0.7 f,16-- }  c2 
  \override Beam.damping = #1
  c''4 \glissando \glissSkip {\glissNote ##f 0.8 f,16-- \glissNote ##f 0.5  
c8-- \glissNote ##f 0.7 f,16-- }  c2 }
%%%

> 
> 
> Cheers,
>  Harm

I’ve been messing a bit with the script placement and managed parts of it, but 
still miss some pieces to get them to look good.

Cheers
/Leo




reply via email to

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