Re: Tweaking glissando timing stems

[Leo Correia de Verdier]

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 
> <leo.correia.de.verdier@gmail.com>:
> 
> 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

> 
>> 
>