Re: Tweaking glissando timing stems
Le 14/11/2021 à 13:49, Thomas Morley a écrit :
Am Fr., 12. Nov. 2021 um 13:44 Uhr schrieb Leo Correia de Verdier
:
Dear Harm and list!
The chords were not that hard to implement. What I did was:
1) Removing the overrides for NoteHead.transparency and NoteHead.Y-offset from
glissandoStemsOn and glissandoStemsOff. Transparency is set for individual
noteheads and used to determine wether a notehead should be printed as usual or
”glissed through”.
2) Adding transparency to the conditions for moving a notehead to the glissando
line.
(ly:grob-property (car nhd-staff-pos) 'transparent #f)
3) resetting the noteheads Y-position only after testing that the notehead in
question should be moved at all, as in the earlier code you’d written (it vas
still in the document, just commented out and replaced by just the variable val)
(+ (/ (cdr nhd-staff-pos) -2) val)
This has not been seriously stresstested, though. It’s still on a "seems to
work” level. A more beautiful solution would probably be to use a dedicated property
instead of piggybacking it on transparency and assuming them identical.
Another thing I found is that TextScript placements are reset as in the example
provided. Can you see any solution for this?
Thanks a lot!
/Leo
Hi Leo,
thanks for testing.
I'm still on it trying to improve things...
There's https://gitlab.com/lilypond/lilypond/-/merge_requests/998 on
the way (thanks Jean). As a result (among others) cross-staff broken
glissandi now work as expected.
Ofcourse I will need to adjust the stemmed glissandi for it, once it
is released.
For now:
Moving NoteHeads depending on their 'transparent property is not that
bad. You coud invent a new property or use a subproperty of 'details
(less invasive). Though, this is a first thought, the final
implementation will differ anyway ...
Regarding the TextScript, this is caused by setting cross-staff.
A minimal (without any glissando-code)
#(ly:set-option 'debug-skylines #t)
{
\override Stem.cross-staff = ##t
\voiceOne
b'4->-"t"
}
Switch between #t and #f
You can work around it with
\version "2.23.5"
{
\override Stem.cross-staff = ##t
\voiceOne
b'4->\tweak cross-staff ##t -"t"
}
It seems related to this old discussion:
https://codereview.appspot.com/106640043
Best,
Jean
Re: Tweaking glissando timing stems
Am Fr., 12. Nov. 2021 um 13:44 Uhr schrieb Leo Correia de Verdier
:
>
> Dear Harm and list!
>
> The chords were not that hard to implement. What I did was:
>
> 1) Removing the overrides for NoteHead.transparency and NoteHead.Y-offset
> from glissandoStemsOn and glissandoStemsOff. Transparency is set for
> individual noteheads and used to determine wether a notehead should be
> printed as usual or ”glissed through”.
>
> 2) Adding transparency to the conditions for moving a notehead to the
> glissando line.
> (ly:grob-property (car nhd-staff-pos) 'transparent #f)
>
> 3) resetting the noteheads Y-position only after testing that the notehead in
> question should be moved at all, as in the earlier code you’d written (it vas
> still in the document, just commented out and replaced by just the variable
> val)
> (+ (/ (cdr nhd-staff-pos) -2) val)
>
> This has not been seriously stresstested, though. It’s still on a "seems to
> work” level. A more beautiful solution would probably be to use a dedicated
> property instead of piggybacking it on transparency and assuming them
> identical.
>
> Another thing I found is that TextScript placements are reset as in the
> example provided. Can you see any solution for this?
>
> Thanks a lot!
> /Leo
Hi Leo,
thanks for testing.
I'm still on it trying to improve things...
There's https://gitlab.com/lilypond/lilypond/-/merge_requests/998 on
the way (thanks Jean). As a result (among others) cross-staff broken
glissandi now work as expected.
Ofcourse I will need to adjust the stemmed glissandi for it, once it
is released.
For now:
Moving NoteHeads depending on their 'transparent property is not that
bad. You coud invent a new property or use a subproperty of 'details
(less invasive). Though, this is a first thought, the final
implementation will differ anyway ...
Regarding the TextScript, this is caused by setting cross-staff.
A minimal (without any glissando-code)
#(ly:set-option 'debug-skylines #t)
{
\override Stem.cross-staff = ##t
\voiceOne
b'4->-"t"
}
Switch between #t and #f
In any case, coding stemmed glissando turns out to be a very hard ...
Cheers,
Harm
Re: Tweaking glissando timing stems
Dear Harm and list! The chords were not that hard to implement. What I did was: 1) Removing the overrides for NoteHead.transparency and NoteHead.Y-offset from glissandoStemsOn and glissandoStemsOff. Transparency is set for individual noteheads and used to determine wether a notehead should be printed as usual or ”glissed through”. 2) Adding transparency to the conditions for moving a notehead to the glissando line. (ly:grob-property (car nhd-staff-pos) 'transparent #f) 3) resetting the noteheads Y-position only after testing that the notehead in question should be moved at all, as in the earlier code you’d written (it vas still in the document, just commented out and replaced by just the variable val) (+ (/ (cdr nhd-staff-pos) -2) val) This has not been seriously stresstested, though. It’s still on a "seems to work” level. A more beautiful solution would probably be to use a dedicated property instead of piggybacking it on transparency and assuming them identical. Another thing I found is that TextScript placements are reset as in the example provided. Can you see any solution for this? Thanks a lot! /Leo glissando-stems-engraver-text-script-example.ly Description: Binary data > 26 okt. 2021 kl. 01:05 skrev Thomas Morley : > > Am Mo., 25. Okt. 2021 um 12:00 Uhr schrieb Leo Correia de Verdier > : >> >> Don’t worry, you’re doing far more on this than anyone could reasonably >> expect. >> >> The final result should be something along these lines, but what I was >> asking about is just the chord possibility. I have looked a little more into >> the code and it’s far far above my level, but I’ve found som places I could >> possibly act on… >> If you don’t have time for it I would be grateful for hints about what I >> could mess around with where in the code. >> >> >> Thanks! >> /Leo > > Hi Leo, > > thanks for the image, I think I understood. > Though, I will first improve the current coding to make it working > with all usual basic cases (and cure some bugs), before I try to > implement other features. Got already some great hints from Jean and > Aaron. > Maybe next weekend ... > > Cheers, > Harm
Re: Tweaking glissando timing stems
Am Mo., 25. Okt. 2021 um 12:00 Uhr schrieb Leo Correia de Verdier : > > Don’t worry, you’re doing far more on this than anyone could reasonably > expect. > > The final result should be something along these lines, but what I was asking > about is just the chord possibility. I have looked a little more into the > code and it’s far far above my level, but I’ve found som places I could > possibly act on… > If you don’t have time for it I would be grateful for hints about what I > could mess around with where in the code. > > > Thanks! > /Leo Hi Leo, thanks for the image, I think I understood. Though, I will first improve the current coding to make it working with all usual basic cases (and cure some bugs), before I try to implement other features. Got already some great hints from Jean and Aaron. Maybe next weekend ... Cheers, Harm
Re: Tweaking glissando timing stems
Don’t worry, you’re doing far more on this than anyone could reasonably expect. The final result should be something along these lines, but what I was asking about is just the chord possibility. I have looked a little more into the code and it’s far far above my level, but I’ve found som places I could possibly act on… If you don’t have time for it I would be grateful for hints about what I could mess around with where in the code. gliss-notehead-example.pdf Description: Adobe PDF document Thanks! /Leo > 25 okt. 2021 kl. 09:42 skrev Thomas Morley : > > Am Mo., 25. Okt. 2021 um 00:02 Uhr schrieb Leo Correia de Verdier > : > >> One feature I would find useful would be the ability to make chords with one >> ”gliss-note” and one regular notehead. I implemented this (not entirely >> successfully) on top of an earlier version of your code by making it work >> only on transparent noteheads and leave untransparent ones where they were >> from start. > > I've no good idea what you'ree after. > Could you post an image? > >> I haven’t had time to read into this version and try to understand >> everything it does yet. Do you have an idea of how readily that could be >> done to this version? > > Well, as said, my autumn break had ended, meaning I'll have far less > time to work on or with LilyPond. > Thus I can't say yet... > > Cheers, > Harm
Re: Tweaking glissando timing stems
Am Mo., 25. Okt. 2021 um 00:02 Uhr schrieb Leo Correia de Verdier : > One feature I would find useful would be the ability to make chords with one > ”gliss-note” and one regular notehead. I implemented this (not entirely > successfully) on top of an earlier version of your code by making it work > only on transparent noteheads and leave untransparent ones where they were > from start. I've no good idea what you'ree after. Could you post an image? > I haven’t had time to read into this version and try to understand everything > it does yet. Do you have an idea of how readily that could be done to this > version? Well, as said, my autumn break had ended, meaning I'll have far less time to work on or with LilyPond. Thus I can't say yet... Cheers, Harm
Re: Tweaking glissando timing stems
Dear Harm! I am very thankful for and moved by the effort you’re putting into this! One feature I would find useful would be the ability to make chords with one ”gliss-note” and one regular notehead. I implemented this (not entirely successfully) on top of an earlier version of your code by making it work only on transparent noteheads and leave untransparent ones where they were from start. I haven’t had time to read into this version and try to understand everything it does yet. Do you have an idea of how readily that could be done to this version? The use case here is that I’m working on a piece for violins, where they play chords consisting of a glissando on one string and repeated notes on an open string. Once again thanks! /Leo > 22 okt. 2021 kl. 10:55 skrev Thomas Morley : > > Am Di., 5. Okt. 2021 um 13:39 Uhr schrieb Leo Correia de Verdier > : >> >> Dear Harm and list! >> >> After almost two years I’m back using this code and found some things I >> would need help with. >> (I have done some additions to it, so it can hackishly handle additional >> noteheads on the stems/notecolumns and also tweaks rests passed by the >> glissando line, byt as I’m not very experienced with code they’re too ugly >> to be posted publicly) >> >> First, when adding more staves the function for the scripts catches the >> scripts of simultaneous note columns in other staves too. I have tried to >> solve this by comparing the staff-symbol associated with them and tried >> getting to them via the NoteColumns, but with no success. >> >> Second, when beam slopes get steep the stems in the middle don’t attach to >> the beams. >> >> Third on the outmost notes, with visible noteheads, the stem connections of >> the noteheads go off. I think the solution would be to use original values >> for their stems instead of calculating them, but that would require some >> extra code for the beams… >> >> If two and three aren’t easy (just that I haven’t been able to solve them) >> they could be bypassed by allowing manual settings for stems, something like >> it’s done with beams. >> >> Would you have time to help me with this? >> >> Thanks! >> /Leo >> >>> 26 okt. 2019 kl. 12:39 skrev Thomas Morley : >>> >>> Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier >>> : >>> I realized that defining the glissando gradient taking the stencil as point of departure, rather than the grob properties, makes it work for broken glissandi too. It was a quite minimal change. (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (* half-line-thick 2)) (+ (- (car stil-x-ext) (cdr stil-x-ext)) (* half-line-thick 2)) (if (> Y-right Y-left) 1 -1))) >>> >>> Yep, meanwhile I did similar, but relying on the actual >>> Glissando.thickness. `half-line-thick´ is derived from >>> staff-symbol-line-thickness, which may result in fishy calculations >>> for changed thicknesses. >>> >>> Attached you'll find a heavily revised code, i.e. a lot clean-up, more >>> respect for user-settings, a plethora of inline comments. >>> Some TODOs inline, the more severe are displayed. >>> >>> Atm, I don't know what could be done further with this approach (apart >>> from said TODOs). >>> Thus I'll wait for feature-requests and bug-reports ;) >>> >>> I said "this approach", because technically speaking it's an override, >>> nothing more. >>> One could think of others: >>> (1) Code an engraver to keep track of all those affected items more >>> easily. NB currently other items like Fingerings, StringNumbers etc >>> are not included. And what about other spanners like Hairpins or >>> TextSpanners. Currently not even tested. >>> (2) Create a new Grob. We already have StemStub and StemTremolo. I >>> could imagine something like GlisandoStem. Ofcourse this would be the >>> most general approach. But also the probably most involved and >>> complicated one. >>> >>> For now I have to stop thinking/coding, though. >>> And monday my autumn-break ends :(( >>> >>> >>> Best, >>> Harm >>> >> > > Hi Leo, > > sorry for the late reply. > During this year's autumn break I had to finish some huge own work, > before I had the opportunity to look into stemmed Glissando again. > > While I can confirm the issues you mentioned, I think the approach via > Glissando.after-line-breaking is not the promising to be finally > successful. > Too many hassles and flaws... > > Thus I tried to follow a different route, not tackling Glissando at > all, but Stems, Beams and NoteHeads, including an engraver (mostly to > set certain pointers). > Afaict, the above mentioned issues are gone, alas some others arose. > The most annoying with added Script. > > Meanwhile I got some hints why it happens and how to solve (probably). > Alas. my autumn break ends soon, I doubt I can proceed much. > Thus, I attach the current state. > > Please, be aware,
Re: Tweaking glissando timing stems
Am Fr., 22. Okt. 2021 um 15:45 Uhr schrieb Thomas Morley
:
>
> Am Fr., 22. Okt. 2021 um 14:48 Uhr schrieb Thomas Morley
> :
> >
> > Am Fr., 22. Okt. 2021 um 14:33 Uhr schrieb Dimitris Marinakis
> > :
> > >
> > > I'd really like to test this version but I'm getting an error :
> > > In procedure ly:grob-object in expression (ly:grob-object stem (quote
> > > glissandi) ...):
> > > Wrong number of arguments to #
> >
> > You need a more recent version, 2.23.3 works here, because I make
> > frequent use of that new feature, thanks Jean.
> >
> > I had not updated the \version
> >
> > Sorry for that,
> > Harm
>
> Next iteration attached, it solves the most annoying issue with
> wrongly placed Script.
>
> Thanks Jean !
>
> Now tackling issue 03 (see resulting pdf) with cross-staff glissando-stems ...
>
> Cheers,
> Harm
Attachment missing...
\version "2.23.3"
#(define glissando-stems
(lambda (grob)
"If @code{NoteColumn.glissando-skip} is set to this procedure, a glissando
skips this @code{NoteColumn} grob and the @code{details.glissando-stems}
property is set @code{#t}."
(ly:grob-set-nested-property! grob '(details glissando-stems) #t)
#t))
#(define-public (line-spanner-gradient stencil grob)
"Takes a line-spanner @var{grob} grob and returns the gradient of the line
looking at @var{stencil}."
(if (and (grob::has-interface grob 'line-interface)
(grob::has-interface grob 'line-spanner-interface))
(let* ((left-bound-info (ly:grob-property grob 'left-bound-info))
(Y-left (assoc-get 'Y left-bound-info))
(X-left (assoc-get 'X left-bound-info))
(left-padding (assoc-get 'padding left-bound-info))
(right-bound-info (ly:grob-property grob 'right-bound-info))
(Y-right (assoc-get 'Y right-bound-info))
(X-right (assoc-get 'X right-bound-info))
(right-padding (assoc-get 'padding right-bound-info))
(x-ext (ly:stencil-extent stencil X))
(y-ext (ly:stencil-extent stencil Y))
(line-thickness (ly:staff-symbol-line-thickness grob))
(grob-thickness (ly:grob-property grob 'thickness #f))
(thick (or grob-thickness line-thickness)))
(/
(- (interval-length y-ext) thick)
(- (interval-length x-ext) thick)
(if (>= (- Y-right Y-left) 0) 1 -1)))
(begin
(ly:warning "Grob ~a is not a line-spanner, returning zero" grob)
0)))
#(define-public (line-spanner-stem-intersection-points refp note-columns grob)
"Takes the @code{Stem} grobs of @var{note-columns} and calculates the
intersection points of @var{grob}, supposed to be a line-spanner, with Y-axis of
the @code{Stem} grobs."
(let* ((grob-relative-coord (ly:grob-relative-coordinate grob refp X))
;; TODO use thicknesses at all? See next TODO
;(line-thickness (ly:staff-symbol-line-thickness grob))
;(half-line-thick (/ line-thickness 2))
;(grob-thickness (ly:grob-property grob 'thickness #f))
;(thick (or grob-thickness line-thickness))
;; stencil-stuff
;; NB ly:line-spanner::print adds half-line-thick to both sides of
;; the line
(stil (ly:line-spanner::print grob))
(stil-x-ext (ly:stencil-extent stil X))
(stil-y-ext (ly:stencil-extent stil Y))
;; left-bound-stuff
(left-bound-info (ly:grob-property grob 'left-bound-info))
(X-left (assoc-get 'X left-bound-info))
(gradient (line-spanner-gradient stil grob))
;; stem-stuff
(stems
(filter-map
(lambda (nc) (ly:grob-object nc 'stem #f))
note-columns))
(stems-x-coords
(map
(lambda (stem) (ly:grob-relative-coordinate stem refp X))
stems)))
;; resulting intersection-points
(map
(lambda (stem-x-coord)
(cons
;; X-coord
(- stem-x-coord
grob-relative-coord)
;; Y-coord
(+
;; Calculate and add the Y-value of the line-spanner at
;; the given stem
;; NB The result is relative to zero-staff-line.
(*
gradient
(- stem-x-coord
grob-relative-coord
(car stil-x-ext)))
;; Thus add the relevant value of line-spanner's y-extent:
;; If the line-spanner points down, use top y-extent,
;; if it points up use bottom y-extent.
;; TODO corrected by half thick? I.e.:
;(if (negative? gradient)
;(- (cdr stil-y-ext) (/ thick 2))
;(+ (car stil-y-ext) (/ thick 2)))
(if (negative? gradient)
(cdr stil-y-ext)
(car stil-y-ext)
stems-x-coords)))
#(define adjust-stems-beams
(lambda (grob)
"Moves @code{NoteHead} grobs passed by one or
Re: Tweaking glissando timing stems
Am Fr., 22. Okt. 2021 um 14:48 Uhr schrieb Thomas Morley : > > Am Fr., 22. Okt. 2021 um 14:33 Uhr schrieb Dimitris Marinakis > : > > > > I'd really like to test this version but I'm getting an error : > > In procedure ly:grob-object in expression (ly:grob-object stem (quote > > glissandi) ...): > > Wrong number of arguments to # > > You need a more recent version, 2.23.3 works here, because I make > frequent use of that new feature, thanks Jean. > > I had not updated the \version > > Sorry for that, > Harm Next iteration attached, it solves the most annoying issue with wrongly placed Script. Thanks Jean ! Now tackling issue 03 (see resulting pdf) with cross-staff glissando-stems ... Cheers, Harm
Re: Tweaking glissando timing stems
Am Fr., 22. Okt. 2021 um 14:33 Uhr schrieb Dimitris Marinakis : > > I'd really like to test this version but I'm getting an error : > In procedure ly:grob-object in expression (ly:grob-object stem (quote > glissandi) ...): > Wrong number of arguments to # You need a more recent version, 2.23.3 works here, because I make frequent use of that new feature, thanks Jean. I had not updated the \version Sorry for that, Harm
Re: Tweaking glissando timing stems
I'd really like to test this version but I'm getting an error : In procedure ly:grob-object in expression (ly:grob-object stem (quote glissandi) ...): Wrong number of arguments to # On Fri, Oct 22, 2021 at 11:57 AM Thomas Morley wrote: > Am Di., 5. Okt. 2021 um 13:39 Uhr schrieb Leo Correia de Verdier > : > > > > Dear Harm and list! > > > > After almost two years I’m back using this code and found some things I > would need help with. > > (I have done some additions to it, so it can hackishly handle additional > noteheads on the stems/notecolumns and also tweaks rests passed by the > glissando line, byt as I’m not very experienced with code they’re too ugly > to be posted publicly) > > > > First, when adding more staves the function for the scripts catches the > scripts of simultaneous note columns in other staves too. I have tried to > solve this by comparing the staff-symbol associated with them and tried > getting to them via the NoteColumns, but with no success. > > > > Second, when beam slopes get steep the stems in the middle don’t attach > to the beams. > > > > Third on the outmost notes, with visible noteheads, the stem connections > of the noteheads go off. I think the solution would be to use original > values for their stems instead of calculating them, but that would require > some extra code for the beams… > > > > If two and three aren’t easy (just that I haven’t been able to solve > them) they could be bypassed by allowing manual settings for stems, > something like it’s done with beams. > > > > Would you have time to help me with this? > > > > Thanks! > > /Leo > > > > > 26 okt. 2019 kl. 12:39 skrev Thomas Morley : > > > > > > Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier > > > : > > > > > >> I realized that defining the glissando gradient taking the stencil as > point of departure, rather than the grob properties, makes it work for > broken glissandi too. It was a quite minimal change. > > >> > > >> (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (* > half-line-thick 2)) > > >>(+ (- (car stil-x-ext) (cdr > stil-x-ext)) (* half-line-thick 2)) > > >>(if (> Y-right Y-left) 1 -1))) > > > > > > Yep, meanwhile I did similar, but relying on the actual > > > Glissando.thickness. `half-line-thick´ is derived from > > > staff-symbol-line-thickness, which may result in fishy calculations > > > for changed thicknesses. > > > > > > Attached you'll find a heavily revised code, i.e. a lot clean-up, more > > > respect for user-settings, a plethora of inline comments. > > > Some TODOs inline, the more severe are displayed. > > > > > > Atm, I don't know what could be done further with this approach (apart > > > from said TODOs). > > > Thus I'll wait for feature-requests and bug-reports ;) > > > > > > I said "this approach", because technically speaking it's an override, > > > nothing more. > > > One could think of others: > > > (1) Code an engraver to keep track of all those affected items more > > > easily. NB currently other items like Fingerings, StringNumbers etc > > > are not included. And what about other spanners like Hairpins or > > > TextSpanners. Currently not even tested. > > > (2) Create a new Grob. We already have StemStub and StemTremolo. I > > > could imagine something like GlisandoStem. Ofcourse this would be the > > > most general approach. But also the probably most involved and > > > complicated one. > > > > > > For now I have to stop thinking/coding, though. > > > And monday my autumn-break ends :(( > > > > > > > > > Best, > > > Harm > > > > > > > Hi Leo, > > sorry for the late reply. > During this year's autumn break I had to finish some huge own work, > before I had the opportunity to look into stemmed Glissando again. > > While I can confirm the issues you mentioned, I think the approach via > Glissando.after-line-breaking is not the promising to be finally > successful. > Too many hassles and flaws... > > Thus I tried to follow a different route, not tackling Glissando at > all, but Stems, Beams and NoteHeads, including an engraver (mostly to > set certain pointers). > Afaict, the above mentioned issues are gone, alas some others arose. > The most annoying with added Script. > > Meanwhile I got some hints why it happens and how to solve (probably). > Alas. my autumn break ends soon, I doubt I can proceed much. > Thus, I attach the current state. > > Please, be aware, it's only an intermediate state! > > Cheers, > Harm >
Re: Tweaking glissando timing stems
Am Di., 5. Okt. 2021 um 13:39 Uhr schrieb Leo Correia de Verdier
:
>
> Dear Harm and list!
>
> After almost two years I’m back using this code and found some things I would
> need help with.
> (I have done some additions to it, so it can hackishly handle additional
> noteheads on the stems/notecolumns and also tweaks rests passed by the
> glissando line, byt as I’m not very experienced with code they’re too ugly to
> be posted publicly)
>
> First, when adding more staves the function for the scripts catches the
> scripts of simultaneous note columns in other staves too. I have tried to
> solve this by comparing the staff-symbol associated with them and tried
> getting to them via the NoteColumns, but with no success.
>
> Second, when beam slopes get steep the stems in the middle don’t attach to
> the beams.
>
> Third on the outmost notes, with visible noteheads, the stem connections of
> the noteheads go off. I think the solution would be to use original values
> for their stems instead of calculating them, but that would require some
> extra code for the beams…
>
> If two and three aren’t easy (just that I haven’t been able to solve them)
> they could be bypassed by allowing manual settings for stems, something like
> it’s done with beams.
>
> Would you have time to help me with this?
>
> Thanks!
> /Leo
>
> > 26 okt. 2019 kl. 12:39 skrev Thomas Morley :
> >
> > Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier
> > :
> >
> >> I realized that defining the glissando gradient taking the stencil as
> >> point of departure, rather than the grob properties, makes it work for
> >> broken glissandi too. It was a quite minimal change.
> >>
> >> (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (*
> >> half-line-thick 2))
> >>(+ (- (car stil-x-ext) (cdr stil-x-ext)) (*
> >> half-line-thick 2))
> >>(if (> Y-right Y-left) 1 -1)))
> >
> > Yep, meanwhile I did similar, but relying on the actual
> > Glissando.thickness. `half-line-thick´ is derived from
> > staff-symbol-line-thickness, which may result in fishy calculations
> > for changed thicknesses.
> >
> > Attached you'll find a heavily revised code, i.e. a lot clean-up, more
> > respect for user-settings, a plethora of inline comments.
> > Some TODOs inline, the more severe are displayed.
> >
> > Atm, I don't know what could be done further with this approach (apart
> > from said TODOs).
> > Thus I'll wait for feature-requests and bug-reports ;)
> >
> > I said "this approach", because technically speaking it's an override,
> > nothing more.
> > One could think of others:
> > (1) Code an engraver to keep track of all those affected items more
> > easily. NB currently other items like Fingerings, StringNumbers etc
> > are not included. And what about other spanners like Hairpins or
> > TextSpanners. Currently not even tested.
> > (2) Create a new Grob. We already have StemStub and StemTremolo. I
> > could imagine something like GlisandoStem. Ofcourse this would be the
> > most general approach. But also the probably most involved and
> > complicated one.
> >
> > For now I have to stop thinking/coding, though.
> > And monday my autumn-break ends :((
> >
> >
> > Best,
> > Harm
> >
>
Hi Leo,
sorry for the late reply.
During this year's autumn break I had to finish some huge own work,
before I had the opportunity to look into stemmed Glissando again.
While I can confirm the issues you mentioned, I think the approach via
Glissando.after-line-breaking is not the promising to be finally
successful.
Too many hassles and flaws...
Thus I tried to follow a different route, not tackling Glissando at
all, but Stems, Beams and NoteHeads, including an engraver (mostly to
set certain pointers).
Afaict, the above mentioned issues are gone, alas some others arose.
The most annoying with added Script.
Meanwhile I got some hints why it happens and how to solve (probably).
Alas. my autumn break ends soon, I doubt I can proceed much.
Thus, I attach the current state.
Please, be aware, it's only an intermediate state!
Cheers,
Harm
\version "2.22.1"
#(define glissando-stems
(lambda (grob)
"If @code{NoteColumn.glissando-skip} is set to this procedure, a glissando
skips this @code{NoteColumn} grob and the @code{details.glissando-stems}
property is set @code{#t}."
(ly:grob-set-nested-property! grob '(details glissando-stems) #t)
#t))
#(define-public (line-spanner-gradient stencil grob)
"Takes a line-spanner @var{grob} grob and returns the gradient of the line
looking at @var{stencil}."
(if (and (grob::has-interface grob 'line-interface)
(grob::has-interface grob 'line-spanner-interface))
(let* ((left-bound-info (ly:grob-property grob 'left-bound-info))
(Y-left (assoc-get 'Y left-bound-info))
(right-bound-info (ly:grob-property grob 'right-bound-info))
(Y-right (assoc-get 'Y right-bound-info))
(x-ext
Re: Tweaking glissando timing stems
Now with the attached example:
When editing the example for the last time before sending it I noticed the
second problem was only in the code I had written myself, and that the
reproduction of it with your code had to do with another issue. In my case it
probably have to do with some flaw in the code for taking additional, non-gloss
noteheads into consideration.
glissando-stems-06-problems.ly
Description: Binary data
> 5 okt. 2021 kl. 13:39 skrev Leo Correia de Verdier
> :
>
> Dear Harm and list!
>
> After almost two years I’m back using this code and found some things I would
> need help with.
> (I have done some additions to it, so it can hackishly handle additional
> noteheads on the stems/notecolumns and also tweaks rests passed by the
> glissando line, byt as I’m not very experienced with code they’re too ugly to
> be posted publicly)
>
> First, when adding more staves the function for the scripts catches the
> scripts of simultaneous note columns in other staves too. I have tried to
> solve this by comparing the staff-symbol associated with them and tried
> getting to them via the NoteColumns, but with no success.
>
> Second, when beam slopes get steep the stems in the middle don’t attach to
> the beams.
>
> Third on the outmost notes, with visible noteheads, the stem connections of
> the noteheads go off. I think the solution would be to use original values
> for their stems instead of calculating them, but that would require some
> extra code for the beams…
>
> If two and three aren’t easy (just that I haven’t been able to solve them)
> they could be bypassed by allowing manual settings for stems, something like
> it’s done with beams.
>
> Would you have time to help me with this?
>
> Thanks!
> /Leo
>
>> 26 okt. 2019 kl. 12:39 skrev Thomas Morley :
>>
>> Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier
>> :
>>
>>> I realized that defining the glissando gradient taking the stencil as point
>>> of departure, rather than the grob properties, makes it work for broken
>>> glissandi too. It was a quite minimal change.
>>>
>>> (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (*
>>> half-line-thick 2))
>>> (+ (- (car stil-x-ext) (cdr stil-x-ext)) (*
>>> half-line-thick 2))
>>> (if (> Y-right Y-left) 1 -1)))
>>
>> Yep, meanwhile I did similar, but relying on the actual
>> Glissando.thickness. `half-line-thick´ is derived from
>> staff-symbol-line-thickness, which may result in fishy calculations
>> for changed thicknesses.
>>
>> Attached you'll find a heavily revised code, i.e. a lot clean-up, more
>> respect for user-settings, a plethora of inline comments.
>> Some TODOs inline, the more severe are displayed.
>>
>> Atm, I don't know what could be done further with this approach (apart
>> from said TODOs).
>> Thus I'll wait for feature-requests and bug-reports ;)
>>
>> I said "this approach", because technically speaking it's an override,
>> nothing more.
>> One could think of others:
>> (1) Code an engraver to keep track of all those affected items more
>> easily. NB currently other items like Fingerings, StringNumbers etc
>> are not included. And what about other spanners like Hairpins or
>> TextSpanners. Currently not even tested.
>> (2) Create a new Grob. We already have StemStub and StemTremolo. I
>> could imagine something like GlisandoStem. Ofcourse this would be the
>> most general approach. But also the probably most involved and
>> complicated one.
>>
>> For now I have to stop thinking/coding, though.
>> And monday my autumn-break ends :((
>>
>>
>> Best,
>> Harm
\version "2.19.83"
%%
%% GLISSANDO WITH STEMS
%%
#(define (glissando-and-stems pad-y)
"Returns the unchanged @code{Glissando}, @code{Stem}s from passed
@code{NoteColumn}s are recreated to start at the glissando-line. @var{pad-y}
may provide a padding-value.
A @code{Flag} is moved to fit again with the new @code{Stem}.
@code{Script} at a passed @code{NoteColumn} is moved to sit at note-head-side.
Inner @code{Beam}s are recreated to be parallel to the glissando-line, unless
an override for @code{Beam.details.beamed-glissando-stem-positions}, expecting
a number-pair, is suppled. This is prefered.
"
;; Glissando has no pointer to the covered NoteColumns, because in most
;; traditional music NoteColumns are *not* skipped.
;; Thus reading those NoteColumns is inconvenient...
(lambda (grob)
(let ((gliss-stil (ly:grob-property grob 'stencil)))
(if (not (ly:stencil? gliss-stil))
;; Warn if no Glissando.stencil is present, do nothing else
(ly:warning "No stencil for ~a found, stopping here" grob)
(let* (
;;
;; some generals
Re: Tweaking glissando timing stems
Dear Harm and list!
After almost two years I’m back using this code and found some things I would
need help with.
(I have done some additions to it, so it can hackishly handle additional
noteheads on the stems/notecolumns and also tweaks rests passed by the
glissando line, byt as I’m not very experienced with code they’re too ugly to
be posted publicly)
First, when adding more staves the function for the scripts catches the scripts
of simultaneous note columns in other staves too. I have tried to solve this by
comparing the staff-symbol associated with them and tried getting to them via
the NoteColumns, but with no success.
Second, when beam slopes get steep the stems in the middle don’t attach to the
beams.
Third on the outmost notes, with visible noteheads, the stem connections of the
noteheads go off. I think the solution would be to use original values for
their stems instead of calculating them, but that would require some extra code
for the beams…
If two and three aren’t easy (just that I haven’t been able to solve them) they
could be bypassed by allowing manual settings for stems, something like it’s
done with beams.
Would you have time to help me with this?
Thanks!
/Leo
> 26 okt. 2019 kl. 12:39 skrev Thomas Morley :
>
> Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier
> :
>
>> I realized that defining the glissando gradient taking the stencil as point
>> of departure, rather than the grob properties, makes it work for broken
>> glissandi too. It was a quite minimal change.
>>
>> (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (*
>> half-line-thick 2))
>>(+ (- (car stil-x-ext) (cdr stil-x-ext)) (*
>> half-line-thick 2))
>>(if (> Y-right Y-left) 1 -1)))
>
> Yep, meanwhile I did similar, but relying on the actual
> Glissando.thickness. `half-line-thick´ is derived from
> staff-symbol-line-thickness, which may result in fishy calculations
> for changed thicknesses.
>
> Attached you'll find a heavily revised code, i.e. a lot clean-up, more
> respect for user-settings, a plethora of inline comments.
> Some TODOs inline, the more severe are displayed.
>
> Atm, I don't know what could be done further with this approach (apart
> from said TODOs).
> Thus I'll wait for feature-requests and bug-reports ;)
>
> I said "this approach", because technically speaking it's an override,
> nothing more.
> One could think of others:
> (1) Code an engraver to keep track of all those affected items more
> easily. NB currently other items like Fingerings, StringNumbers etc
> are not included. And what about other spanners like Hairpins or
> TextSpanners. Currently not even tested.
> (2) Create a new Grob. We already have StemStub and StemTremolo. I
> could imagine something like GlisandoStem. Ofcourse this would be the
> most general approach. But also the probably most involved and
> complicated one.
>
> For now I have to stop thinking/coding, though.
> And monday my autumn-break ends :((
>
>
> Best,
> Harm
\version "2.19.83"
%%
%% GLISSANDO WITH STEMS
%%
#(define (glissando-and-stems pad-y)
"Returns the unchanged @code{Glissando}, @code{Stem}s from passed
@code{NoteColumn}s are recreated to start at the glissando-line. @var{pad-y}
may provide a padding-value.
A @code{Flag} is moved to fit again with the new @code{Stem}.
@code{Script} at a passed @code{NoteColumn} is moved to sit at note-head-side.
Inner @code{Beam}s are recreated to be parallel to the glissando-line, unless
an override for @code{Beam.details.beamed-glissando-stem-positions}, expecting
a number-pair, is suppled. This is prefered.
"
;; Glissando has no pointer to the covered NoteColumns, because in most
;; traditional music NoteColumns are *not* skipped.
;; Thus reading those NoteColumns is inconvenient...
(lambda (grob)
(let ((gliss-stil (ly:grob-property grob 'stencil)))
(if (not (ly:stencil? gliss-stil))
;; Warn if no Glissando.stencil is present, do nothing else
(ly:warning "No stencil for ~a found, stopping here" grob)
(let* (
;;
;; some generals
;;
(sys (ly:grob-system grob))
(layout (ly:grob-layout grob))
(blot (ly:output-def-lookup layout 'blot-diameter))
(staff-space (ly:staff-symbol-staff-space grob))
(line-thickness (ly:staff-symbol-line-thickness grob))
(half-line-thick (/ line-thickness 2))
(grob-thickness (ly:grob-property grob 'thickness 1))
(gliss-thick (* line-thickness grob-thickness))
;; We use original not grob here to avoid not
Re: Tweaking glissando timing stems
Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier
:
> I realized that defining the glissando gradient taking the stencil as point
> of departure, rather than the grob properties, makes it work for broken
> glissandi too. It was a quite minimal change.
>
> (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (*
> half-line-thick 2))
> (+ (- (car stil-x-ext) (cdr stil-x-ext)) (*
> half-line-thick 2))
> (if (> Y-right Y-left) 1 -1)))
Yep, meanwhile I did similar, but relying on the actual
Glissando.thickness. `half-line-thick´ is derived from
staff-symbol-line-thickness, which may result in fishy calculations
for changed thicknesses.
Attached you'll find a heavily revised code, i.e. a lot clean-up, more
respect for user-settings, a plethora of inline comments.
Some TODOs inline, the more severe are displayed.
Atm, I don't know what could be done further with this approach (apart
from said TODOs).
Thus I'll wait for feature-requests and bug-reports ;)
I said "this approach", because technically speaking it's an override,
nothing more.
One could think of others:
(1) Code an engraver to keep track of all those affected items more
easily. NB currently other items like Fingerings, StringNumbers etc
are not included. And what about other spanners like Hairpins or
TextSpanners. Currently not even tested.
(2) Create a new Grob. We already have StemStub and StemTremolo. I
could imagine something like GlisandoStem. Ofcourse this would be the
most general approach. But also the probably most involved and
complicated one.
For now I have to stop thinking/coding, though.
And monday my autumn-break ends :((
Best,
Harm
\version "2.19.83"
%%
%% GLISSANDO WITH STEMS
%%
#(define (glissando-and-stems pad-y)
"Returns the unchanged @code{Glissando}, @code{Stem}s from passed
@code{NoteColumn}s are recreated to start at the glissando-line. @var{pad-y}
may provide a padding-value.
A @code{Flag} is moved to fit again with the new @code{Stem}.
@code{Script} at a passed @code{NoteColumn} is moved to sit at note-head-side.
Inner @code{Beam}s are recreated to be parallel to the glissando-line, unless
an override for @code{Beam.details.beamed-glissando-stem-positions}, expecting
a number-pair, is suppled. This is prefered.
"
;; Glissando has no pointer to the covered NoteColumns, because in most
;; traditional music NoteColumns are *not* skipped.
;; Thus reading those NoteColumns is inconvenient...
(lambda (grob)
(let ((gliss-stil (ly:grob-property grob 'stencil)))
(if (not (ly:stencil? gliss-stil))
;; Warn if no Glissando.stencil is present, do nothing else
(ly:warning "No stencil for ~a found, stopping here" grob)
(let* (
;;
;; some generals
;;
(sys (ly:grob-system grob))
(layout (ly:grob-layout grob))
(blot (ly:output-def-lookup layout 'blot-diameter))
(staff-space (ly:staff-symbol-staff-space grob))
(line-thickness (ly:staff-symbol-line-thickness grob))
(half-line-thick (/ line-thickness 2))
(grob-thickness (ly:grob-property grob 'thickness 1))
(gliss-thick (* line-thickness grob-thickness))
;; We use original not grob here to avoid not catching some
;; elements for broken glissando.
(original (ly:grob-original grob))
(left-bound (ly:spanner-bound original LEFT))
(right-bound (ly:spanner-bound original RIGHT))
(left-bound-when (grob::when left-bound))
(right-bound-when (grob::when right-bound))
;; Glissando-stencil extents
(gliss-stil-x-ext (ly:stencil-extent gliss-stil X))
(gliss-stil-y-ext (ly:stencil-extent gliss-stil Y))
;;
;; Glissando-slope
;;
;; The actual used glissando-gradient (calculated below) is
;; influenced by positive or negative slope.
;;
;; Simple slope could be retrieved by comparing Y-left/right.
;; We need X-left lateron, so we see no real need for
;; simplification here.
(left-bound-info (ly:grob-property grob 'left-bound-info))
(X-left (assoc-get 'X left-bound-info))
(Y-left (assoc-get 'Y left-bound-info))
(right-bound-info (ly:grob-property grob 'right-bound-info))
(X-right (assoc-get
Re: Tweaking glissando timing stems
Brilliant! I realized that defining the glissando gradient taking the stencil as point of departure, rather than the grob properties, makes it work for broken glissandi too. It was a quite minimal change. (gliss-gradient (/ (+ (- (car stil-y-ext) (cdr stil-y-ext)) (* half-line-thick 2)) (+ (- (car stil-x-ext) (cdr stil-x-ext)) (* half-line-thick 2)) (if (> Y-right Y-left) 1 -1))) Like glissando-stems-05.ly Description: Binary data > 22 okt. 2019 kl. 13:33 skrev Thomas Morley : > > Am Sa., 19. Okt. 2019 um 12:36 Uhr schrieb Thomas Morley > : > >> 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. > > Attached the next iteration. > Per default all Beams are parallel to the glissando. > Though, I implemented the possibility to reset their position by using > the new introduced subproperty beamed-glissando-stem-positions of > details. > See examples (with unusual values, just to see it works) > > Broken glissandi are not yet supported, the code will not error, but > the numerical calculations are not longer correct in this case. > > At any rate, the code becomes a monster lol > > Cheers, > Harm \version "2.19.83" #(define (make-cross-stencil coords) (let ((thick 0.1) (sz 0.2)) (ly:stencil-add (make-line-stencil thick (- (car coords) sz) (- (cdr coords) sz) (+ (car coords) sz) (+ (cdr coords) sz)) (make-line-stencil thick (- (car coords) sz) (+ (cdr coords) sz) (+ (car coords) sz) (- (cdr coords) sz) #(define (line-gradient x-positions y-positions) (/ (- (cdr y-positions) (car y-positions)) (- (cdr x-positions) (car x-positions %% Glissando has no pointer to the covered NoteColumns, because in most %% traditional music NoteColumns are *not* skipped. %% Thus reading those NoteColumns is inconvenient. #(define (glissando-and-stems pad-y) (lambda (grob) (let* ((layout (ly:grob-layout grob)) (blot (ly:output-def-lookup layout 'blot-diameter)) (staff-space (ly:staff-symbol-staff-space grob)) (half-line-thick (/ (ly:staff-symbol-line-thickness grob) 2)) (original (ly:grob-original grob)) (left-bound (ly:spanner-bound original LEFT)) (right-bound (ly:spanner-bound original RIGHT)) (left-bound-when (grob::when left-bound)) (right-bound-when (grob::when right-bound)) (stil (ly:grob-property grob 'stencil)) ;(stil (ly:line-spanner::print grob)) (stil-x-ext (ly:stencil-extent stil X)) (stil-y-ext (ly:stencil-extent stil Y)) (left-bound-info (ly:grob-property grob 'left-bound-info)) (X-left (assoc-get 'X left-bound-info)) (Y-left (assoc-get 'Y left-bound-info)) (left-padding (assoc-get 'padding left-bound-info)) (right-bound-info (ly:grob-property grob 'right-bound-info)) (X-right (assoc-get 'X right-bound-info)) (Y-right (assoc-get 'Y right-bound-info)) (gliss-gradient (/ (- Y-right Y-left) (- X-right X-left))) (sys (ly:grob-system grob)) (sys-elts-array (ly:grob-object sys 'all-elements)) (ncs (filter (lambda (elt) (let (;; Going for `ly:grob-relative-coordinate´ disturbs ;; vertical spacing, thus we sort/filter using ;; `grob::when´ (elt-when (grob::when elt))) (and (grob::has-interface elt 'note-column-interface) (ly:grob-property elt 'glissando-skip #f) (ly:grob-array? (ly:grob-object elt 'note-heads)) (ly:momentlist sys-elts-array))) ;; Stems from all NoteColumns covered by the Glissando (stems (map (lambda (nc) (ly:grob-object nc 'stem)) ncs)) ;; Mmhh, why do we need that? (stem-begin-positions (map (lambda (stem) (ly:grob-property stem 'stem-begin-position)) stems)) (stem-x-coord-proc (lambda (nc) (ly:grob-relative-coordinate (ly:grob-object nc 'stem) sys X))) (stems-x-coords (map stem-x-coord-proc ncs)) ;; TODO for broken glissandi this is not exact (gliss-stem-intersections (map (lambda (stem-x-coord) (cons ;; TODO do we need the x-value at all? (+ (- stem-x-coord X-left)
Re: Tweaking glissando timing stems
Am Sa., 19. Okt. 2019 um 12:36 Uhr schrieb Thomas Morley : > 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. Attached the next iteration. Per default all Beams are parallel to the glissando. Though, I implemented the possibility to reset their position by using the new introduced subproperty beamed-glissando-stem-positions of details. See examples (with unusual values, just to see it works) Broken glissandi are not yet supported, the code will not error, but the numerical calculations are not longer correct in this case. At any rate, the code becomes a monster lol Cheers, Harm \version "2.19.83" #(define (make-cross-stencil coords) (let ((thick 0.1) (sz 0.2)) (ly:stencil-add (make-line-stencil thick (- (car coords) sz) (- (cdr coords) sz) (+ (car coords) sz) (+ (cdr coords) sz)) (make-line-stencil thick (- (car coords) sz) (+ (cdr coords) sz) (+ (car coords) sz) (- (cdr coords) sz) #(define (line-gradient x-positions y-positions) (/ (- (cdr y-positions) (car y-positions)) (- (cdr x-positions) (car x-positions %% Glissando has no pointer to the covered NoteColumns, because in most %% traditional music NoteColumns are *not* skipped. %% Thus reading those NoteColumns is inconvenient. #(define (glissando-and-stems pad-y) (lambda (grob) (let* ((layout (ly:grob-layout grob)) (blot (ly:output-def-lookup layout 'blot-diameter)) (staff-space (ly:staff-symbol-staff-space grob)) (half-line-thick (/ (ly:staff-symbol-line-thickness grob) 2)) (original (ly:grob-original grob)) (left-bound (ly:spanner-bound original LEFT)) (right-bound (ly:spanner-bound original RIGHT)) (left-bound-when (grob::when left-bound)) (right-bound-when (grob::when right-bound)) (stil (ly:grob-property grob 'stencil)) ;(stil (ly:line-spanner::print grob)) (stil-x-ext (ly:stencil-extent stil X)) (stil-y-ext (ly:stencil-extent stil Y)) (left-bound-info (ly:grob-property grob 'left-bound-info)) (X-left (assoc-get 'X left-bound-info)) (Y-left (assoc-get 'Y left-bound-info)) (left-padding (assoc-get 'padding left-bound-info)) (right-bound-info (ly:grob-property grob 'right-bound-info)) (X-right (assoc-get 'X right-bound-info)) (Y-right (assoc-get 'Y right-bound-info)) (gliss-gradient (/ (- Y-right Y-left) (- X-right X-left))) (sys (ly:grob-system grob)) (sys-elts-array (ly:grob-object sys 'all-elements)) (ncs (filter (lambda (elt) (let (;; Going for `ly:grob-relative-coordinate´ disturbs ;; vertical spacing, thus we sort/filter using ;; `grob::when´ (elt-when (grob::when elt))) (and (grob::has-interface elt 'note-column-interface) (ly:grob-property elt 'glissando-skip #f) (ly:grob-array? (ly:grob-object elt 'note-heads)) (ly:momentlist sys-elts-array))) ;; Stems from all NoteColumns covered by the Glissando (stems (map (lambda (nc) (ly:grob-object nc 'stem)) ncs)) ;; Mmhh, why do we need that? (stem-begin-positions (map (lambda (stem) (ly:grob-property stem 'stem-begin-position)) stems)) (stem-x-coord-proc (lambda (nc) (ly:grob-relative-coordinate (ly:grob-object nc 'stem) sys X))) (stems-x-coords (map stem-x-coord-proc ncs)) ;; TODO for broken glissandi this is not exact (gliss-stem-intersections (map (lambda (stem-x-coord) (cons ;; TODO do we need the x-value at all? (+ (- stem-x-coord X-left) (- (car stil-x-ext) left-padding) half-line-thick) (+ (* gliss-gradient (+ (- stem-x-coord X-left) (- (car stil-x-ext) left-padding) half-line-thick (- (+ (car stil-x-ext) half-line-thick (if (negative? gliss-gradient) (- (cdr stil-y-ext) half-line-thick) (+ (car stil-y-ext)
Re: Tweaking glissando timing stems
> 19 okt. 2019 kl. 12:36 skrev Thomas Morley :
>
> Am Sa., 19. Okt. 2019 um 00:01 Uhr schrieb Leo Correia de Verdier
> :
>>
>> 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
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking glissando timing stems
Am Sa., 19. Okt. 2019 um 00:01 Uhr schrieb Leo Correia de Verdier
:
>
> 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
Re: Tweaking glissando timing stems
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 :
>
> Am Mo., 14. Okt. 2019 um 12:22 Uhr schrieb Leo Correia de Verdier
> :
>
>> 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
Re: Tweaking glissando timing stems
Am Mo., 14. Okt. 2019 um 12:22 Uhr schrieb Leo Correia de Verdier : > 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
Re: Tweaking glissando timing stems
Thank you very much!
Since I’m not very experienced with either lilypond or programming in general
this will be a lot for me to break up, understand and work with, but it
contains most of what I need. Now I’ll go and do my homework for some days (or
even longer). In some time I’ll be back with results, whether they’ll be usable
or not remains to be seen. The beams are needed for it to be really useful for
me, but I’ll give script positions, slur positions and ability to handle broken
glissandi at least some thought too.
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?
Cheers
/Leo
> 13 okt. 2019 kl. 19:23 skrev Thomas Morley :
>
> Am Do., 10. Okt. 2019 um 14:51 Uhr schrieb Leo Correia de Verdier
> :
>>
>> Dear list!
>>
>> I'm soon going to start engraving a piece that contains very many glissandi
>> with timing marks (or actually, glissandi with broken bowing and
>> articulations during the way). The snippet in
>> http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-as-lines#glissando
>> mentions the stems might need to be repositioned slightly, and I was
>> wondering if this would be possible to automate.
>>
>> I realize this will be complicated, since it (as I understand it at least)
>> will require changing stem lengths and notehead attachments after the
>> horizontal spacing is calculated (possibly changing pitches too, but the
>> solution I’m imagining would not do that). So I would need to access the
>> calculated positions of the stems and of the endpoints of the glissando. Is
>> that possible? Where and what do I need to read up to accomplish it? Or has
>> someone already done something similar?
>>
>> I have seen Piaras Hobans code in this thread:
>> https://lists.gnu.org/archive/html/lilypond-user/2014-03/msg00717.html , and
>> it’s interesting for me, but it relies on the stems being equally spaced,
>> which they shouldn’t be in my case.
>>
>> In the following example I’m looking for a way to calculate up and y-diff in
>> the glissNote function, instead of having to type them in by hand after
>> looking at the resulting score. (The gap between the stems and
>> glissando-line is intentional, the articulation positioning is just not done
>> yet). I have not done it minimal because I wanted to give a glimpse of the
>> point of the notation also.
>>
>> %
>>
>> \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 #} )
>>
>> glissRest = #(define-music-function (staff-position rest) (number? ly:music?)
>> #{ \tweak Y-offset #staff-position
>> \tweak layer #-1
>> \tweak whiteout #10
>> \parenthesize
>> #rest #} )
>>
>> glissSkip = #(define-music-function (music) (ly:music?)
>> #{ \override NoteColumn.glissando-skip = ##t
>> #music
>> \revert NoteColumn.glissando-skip #} )
>>
>> \relative c'' {
>> \time 6/8
>> \set glissandoMap = #'((1 . 1))
>> 16-> -\tweak layer #-2 \glissando
>> \glissSkip {
>>8-. 16-. > ##f #.1 f'>8->
>><< {\glissRest #2.5 r8 s4} \\
>> {d,8_-_> ^. ^.}
>> >>
>> }
>> \time 2/4 2--
>> }
>>
>> %%
>>
>> Thanks a lot!
>> /Leo
>
> Hi Leo,
>
> the topic of glissando-stems pops up from time to time.
> See older discussions, p.e. here:
> https://codereview.appspot.com/4661061/#ps1
>
> Some time ago I started to code something in this regard and took your
> request to polish it a bit.
> Though, there are still some TODOs:
> - Scripts are not always positioned nicely.
> - "Inner" beams 'positions can't be affected from
> Glissando.after-line-breaking.
> etc
>
> Furthermore I'm not sure the whole approach fits your needs.
> Nevertheless the code is attached, probably you'll find the
> calculation for "gliss-stem-intersections" helpful.
>
> Cheers,
> Harm
\version "2.19.83"
#(define (make-cross-stencil coords)
(let ((thick 0.1)
(sz 0.2))
(ly:stencil-add
(make-line-stencil
thick
(- (car coords) sz)
(- (cdr coords) sz)
(+ (car coords) sz)
(+ (cdr coords) sz))
(make-line-stencil
thick
(- (car coords) sz)
(+ (cdr coords) sz)
(+ (car coords) sz)
(- (cdr coords) sz)
%% Glissando has no pointer to the covered NoteColumns, because in most
%% traditional music NoteColumns are *not* skipped.
%% Thus reading those NoteColumns is inconvenient.
%% Correcting Beam.positions is impossible here either. For this pupose an
%% additional override is needed.
#(define
Re: Tweaking glissando timing stems
Am Do., 10. Okt. 2019 um 14:51 Uhr schrieb Leo Correia de Verdier
:
>
> Dear list!
>
> I'm soon going to start engraving a piece that contains very many glissandi
> with timing marks (or actually, glissandi with broken bowing and
> articulations during the way). The snippet in
> http://lilypond.org/doc/v2.19/Documentation/notation/expressive-marks-as-lines#glissando
> mentions the stems might need to be repositioned slightly, and I was
> wondering if this would be possible to automate.
>
> I realize this will be complicated, since it (as I understand it at least)
> will require changing stem lengths and notehead attachments after the
> horizontal spacing is calculated (possibly changing pitches too, but the
> solution I’m imagining would not do that). So I would need to access the
> calculated positions of the stems and of the endpoints of the glissando. Is
> that possible? Where and what do I need to read up to accomplish it? Or has
> someone already done something similar?
>
> I have seen Piaras Hobans code in this thread:
> https://lists.gnu.org/archive/html/lilypond-user/2014-03/msg00717.html , and
> it’s interesting for me, but it relies on the stems being equally spaced,
> which they shouldn’t be in my case.
>
> In the following example I’m looking for a way to calculate up and y-diff in
> the glissNote function, instead of having to type them in by hand after
> looking at the resulting score. (The gap between the stems and glissando-line
> is intentional, the articulation positioning is just not done yet). I have
> not done it minimal because I wanted to give a glimpse of the point of the
> notation also.
>
> %
>
> \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 #} )
>
> glissRest = #(define-music-function (staff-position rest) (number? ly:music?)
>#{ \tweak Y-offset #staff-position
> \tweak layer #-1
> \tweak whiteout #10
> \parenthesize
> #rest #} )
>
> glissSkip = #(define-music-function (music) (ly:music?)
>#{ \override NoteColumn.glissando-skip = ##t
> #music
> \revert NoteColumn.glissando-skip #} )
>
> \relative c'' {
> \time 6/8
> \set glissandoMap = #'((1 . 1))
> 16-> -\tweak layer #-2 \glissando
> \glissSkip {
> 8-. 16-. ##f #.1 f'>8->
> << {\glissRest #2.5 r8 s4} \\
>{d,8_-_> ^. ^.}
> >>
> }
> \time 2/4 2--
> }
>
> %%
>
> Thanks a lot!
> /Leo
Hi Leo,
the topic of glissando-stems pops up from time to time.
See older discussions, p.e. here:
https://codereview.appspot.com/4661061/#ps1
Some time ago I started to code something in this regard and took your
request to polish it a bit.
Though, there are still some TODOs:
- Scripts are not always positioned nicely.
- "Inner" beams 'positions can't be affected from Glissando.after-line-breaking.
etc
Furthermore I'm not sure the whole approach fits your needs.
Nevertheless the code is attached, probably you'll find the
calculation for "gliss-stem-intersections" helpful.
Cheers,
Harm
\version "2.19.83"
#(define (make-cross-stencil coords)
(let ((thick 0.1)
(sz 0.2))
(ly:stencil-add
(make-line-stencil
thick
(- (car coords) sz)
(- (cdr coords) sz)
(+ (car coords) sz)
(+ (cdr coords) sz))
(make-line-stencil
thick
(- (car coords) sz)
(+ (cdr coords) sz)
(+ (car coords) sz)
(- (cdr coords) sz)
%% Glissando has no pointer to the covered NoteColumns, because in most
%% traditional music NoteColumns are *not* skipped.
%% Thus reading those NoteColumns is inconvenient.
%% Correcting Beam.positions is impossible here either. For this pupose an
%% additional override is needed.
#(define (glissando-and-stems pad-y)
(lambda (grob)
(let* ((layout (ly:grob-layout grob))
(blot (ly:output-def-lookup layout 'blot-diameter))
(staff-symbol (ly:grob-object grob 'staff-symbol))
(staff-symbol-line-positions
(ly:grob-property staff-symbol 'line-positions '(-4 -2 0 2 4)))
(top-staff-line (apply max staff-symbol-line-positions))
(bottom-staff-line (apply min staff-symbol-line-positions))
(staff-space (ly:staff-symbol-staff-space grob))
(half-line-thick (/ (ly:staff-symbol-line-thickness grob) 2))
(original (ly:grob-original grob))
(left-bound (ly:spanner-bound original LEFT))
(right-bound (ly:spanner-bound original RIGHT))
(left-bound-when (grob::when left-bound))
(right-bound-when (grob::when right-bound))
;(stil (ly:grob-property grob 'stencil))
(stil (ly:line-spanner::print
