Re: Start, end, gradient of Glissando

[Thomas Morley]

Am So., 24. Okt. 2021 um 16:35 Uhr schrieb Aaron Hill
<lilypond@hillvisions.com>:
>
> On 2021-10-24 6:22 am, Thomas Morley wrote:
> > Though, how could I have found it myself?
> > My lack of C++-knowledge hinders me to understand the "logic from
> > Line_spanner::print". I usually learn things from looking at
> > scheme-codings.
>
> Not sure it would have been clear without digging into the print
> function.  For reference, here are the relevant lines:
>
> ////
>    Interval normalized_endpoints = from_scm (get_property (me,
> "normalized-endpoints"), Interval (0, 1));
>    Real y_length = span_points[RIGHT][Y_AXIS] -
> span_points[LEFT][Y_AXIS];
>
>    span_points[LEFT][Y_AXIS] += normalized_endpoints[LEFT] * y_length;
>    span_points[RIGHT][Y_AXIS] -= (1 - normalized_endpoints[RIGHT]) *
> y_length;
> ////

Yeah, I found them already, but I have even difficulties to decipher
what's a varable, what's an operation, what's a procedure ...

> > But there is none in our source using 'normalized-endpoints, apart
> > from setting it in some grob-definitions.
> > The description reads: "Represents left and right placement over the
> > _total_ spanner, where the _width_ of the spanner is normalized
> > between 0 and 1."
> > I think the wording is misleading, at least "total" means the unbroken
> > spanner for me, thus I never considered to look at it for broken
> > spanners.
> > The word "width" means the extent in X-axis direction, again no reason
> > to look at it for extents in Y-axis.
>
> You are right that "width" is talking about the X extent, but "total"
> does not just mean an unbroken spanner but the entire spanner, broken or
> otherwise.

Well, my first thought about it was different.
Maybe I find a better wording, then I'll put up a patch.

> The resulting normalized values are in essence percentages
> of the total width if you were to lay each broken element end-to-end.
> For example, if a spanner is broken into two parts of equal size, then
> you should see normalized-endpoints as the intervals [0, 0.5] and [0.5,
> 1].
>
>
> > P.S.
> > While the Y-values are fixed now, I found some flaw, if left/right
> > padding is not zero. At least for broken or cross-staff Glissando.
> > I'll continue research..., unless someone has another hint?

Meanwhile I found the culprit with non-zero paddings, see attached.

> Yup, there's more code in Line_spanner::print that factors in the
> padding values.  It is perhaps harder to locate because the variable was
> named "gaps".  And it turns out there is more than just padding that
> will affect your calculation.  Try setting a stencil in either
> bound-details, as that will also shorten the effective spanner line.
> Arrows, however, seem to overlay on the line without changing its
> length.
>
> Let me take a stab at converting the print routine to Scheme.

Would be great !!

> -- Aaron Hill

Best,
  Harm

start-end-gradient-04.ly
Description: Text Data