Re: Slur with left and/or right arrow head

[Thomas Morley]

Am Mi., 17. Apr. 2019 um 10:13 Uhr schrieb Lukas-Fabian Moser <address@hidden>:

Hi Lukas,

> As to the interface: For, e.g., Glissandos, an arrow tip (not as
> beautiful as your Slur arrow) is activated by issuing \overriding
> Glissando.bound-details.left.arrow = ##t. I asked myself whether it's
> good to have this difference in the interface for Slur arrows where you
> use details instead of bound-details and a signed value (#LEFT and
> #RIGHT), seeing that Slur.details.arrow-right = #LEFT doesn't give a
> reasonable result anyway (at the moment). But I do not really know what
> the conceptual difference of details vs. bound-details is, anyway.

Well, it's a little cheating involved :)
LilyPond does checks for grob-properties, you can't write
\override Grob.self-invited-property = ...
without "explaining" this `self-invited-property´ to LilyPond.

But details and bound-details are established properties taking alists
containing key-value-pairs of subproperties.
Adding a new one like `arrow-left´ will not disturb other procedures
reading `(bound-)details´, they simply don't look for the new ones
(ofcourse you need to care not to take a preserved one). There is no
checking of subproperties.
So I code frequently this way.

I believe bound-details is more common for grobs with the
line-spanner-interface, but it makes no real difference, afaik.

I'm aware doing
arrow-left -> LEFT
arrow-right -> RIGHT
is not that elegant, but thee are two names needed with three options
LEFT/RIGHT/#f
I'll have to think over it.

>
> Harm, the old code for outside-staff-curve still works with this
> solution, so it could be re-used if needed (might be appropriate for my
> use case).

Nice to hear, I didn't check the old outside-staff-curve part.

> Concerning my request for "the option to have an arrow tip at both ends
> of the Slur": This is now already implemented since left and right arrow
> tip can be activated independently and/or simultaneously.
>
> I'm undecided as to the desired behaviour with broken Slurs. For me,
> it's all about graphical annotations in very short "scores" in a music
> theory setting where I'll make sure that there are no line-breaks
> anyway. But of course there might be good reasons to use
> slurs-with-arrow-tips in "real life" scores where one might wish for a
> reasonable handling of arrowed broken slurs. I can imagine three
> possibilities:
>
> a) arrow head only at the last (resp. first for arrow-left) broken slur
>
> b) arrow head at each broken curve (current situation)

Well, I'll then leave it it as is for now. Maybe one can get there by
adding some code like alterBroken.

> b') arrow head at each broken curve, but partly dashed slur at breaking
> points. I try to sketch this in attached image.

Same here, alterBroken may do it.

> To be clear: I do not need this functionality at all, but only wanted to
> give an input regarding the possibly reasonable design behaviours. What
> do you think?
>
> Lukas
>

Best,
  Harm