Re: Slur with left and/or right arrow head

[Thomas Morley]

Am Di., 16. Apr. 2019 um 23:45 Uhr schrieb Aaron Hill
<address@hidden>:
>
> On 2019-04-16 10:37 am, Thomas Morley wrote:
> > Am Mo., 15. Apr. 2019 um 19:26 Uhr schrieb Lukas-Fabian Moser
> > <address@hidden>:
> >>
> >> Folks,
> >>
> >> in
> >> https://archiv.lilypondforum.de/index.php?topic=1744.msg9669#msg9669,
> >> Harm invented a truly wonderful new feature allowing to add an arrow
> >> head to the right end of a Slur (or, for that matter, a Tie,
> >> PhrasingSlur etc.). I reproduce it here with only trivial changes
> >> (mainly omitting parser/location).
> >>
> >> Now I also need slurs with arrows pointing to the left (and ideally,
> >> also the option to have an arrow tip at both ends of the Slur). At
> >> first
> >> glance the asymmetry favoring the right hand side of a Slur seems to
> >> be
> >> hard-coded pretty deeply in Harm's code. Is there a cheap way to add a
> >> choice of "left or right end" (if not even the "or/and" possibility)?
> >>
> >> Best
> >> Lukas
> >
> > Hi Lukas,
> >
> > I started to implement the functionality, finally I more or less
> > rewrote anything.
> > As David K once said: rewriting all means at least knowing where the
> > bugs are...
>
> Harm,
>
> There is an annoying optical issue where using the angle of the curve at
> the end points does not work well for an arrow head that partially
> overlaps the curve.  Instead, one needs to consider the slope of the
> curve a little inwards from the ends so that the arrow appears to be
> aligned properly.
>
> I took a stab at patching your code to address this.  This involved some
> additional computational work for various metrics of a Bezier curve.
> See the attached files.

Hi Aaron,

thanks a lot for this.
I was aware of not going for the bezier-curve itself, but only for the
control-points was a raw approximation.
Yours is far better.
Mostly I did so for reasons of lacking knowledge of beziers, both the
math and how to compute them.
Now there is a fine tool-set available, many thanks again.
I tried to understand what you coded (not finished yet), but while
playing around with code I always think making it visible will help.
Thus the attached file and image.
One question I really couldn't answer is:
What kind of value is `t´ in (define (bezier-angle control-points t) ...)
Seems not to be a x- or y-value, not an arc-length-value .., but what else?

Now all those nice bezier-tools are done I made some performance tests.
Running my arrow-slur-03.ly gives
real 0m4,318s
user 0m4,000s
sys 0m0,272s

Your arrow-slur-03-patch.ly is a little slower
real 0m4,661s
user 0m4,075s
sys 0m0,562s

I posted the best values of multiple runs for both.

I then implemented a counter in your (bezier-curve control-points t).
It's called scaring 78368 times, which may explain it.

> Among the things I changed is that the code that adds the arrows to the
> ends of the curve no longer applies an offset.  This offset was strictly
> horizontal which did not work well for more heavily rotated arrows.
> Instead, the offset is done within the code that computes and rotates
> the arrow, so that the center of rotation is properly defined.  What I
> found is that no special case for ties needed to be applied, as the
> results looked uniform between the different grobs.

Up to now I didn't look at that part of your changes, was playing with
a new set of (bezier-)toys, lol

> Also, I "fixed" the font-size issue by bypassing the font settings
> within the grob itself, because simply scaling the glyph results in
> thicker lines.  So while font-size is now consistent between the
> different grobs, it is unfortunately now a hard-coded value.  I am
> uncertain whether this tradeoff would be acceptable.

Not sure either, why does Tie has a font-size property at all?

Best,
  Harm

bezier-tests-02.ly
Description: Text Data

bezier-tests-02.pdf
Description: Adobe PDF document