Re: Tweaking glissando timing stems

[Leo Correia de Verdier]

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 <thomasmorley65@gmail.com>:
> 
> Am Di., 5. Okt. 2021 um 13:39 Uhr schrieb 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
>>> 
>> 
> 
> 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

glissando-stems-engraver-08.ly
Description: Binary data

glissando-stems-engraver-08.pdf
Description: Adobe PDF document

>