[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Start, end, gradient of Glissando

From: Aaron Hill
Subject: Re: Start, end, gradient of Glissando
Date: Sun, 24 Oct 2021 07:35:19 -0700
User-agent: Roundcube Webmail/1.4.9

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

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;

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
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. 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].

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?

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.

-- Aaron Hill

reply via email to

[Prev in Thread] Current Thread [Next in Thread]