Re: Tweaking glissando timing stems

[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 <thomasmorley65@gmail.com>:
> 
> Am Fr., 25. Okt. 2019 um 22:41 Uhr schrieb Leo Correia de Verdier
> <leo.correia.de.verdier@gmail.com>:
> 
>> 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

glissando-stems-06.ly
Description: Text Data

>