[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Slur with left and/or right arrow head
From: |
Thomas Morley |
Subject: |
Re: Slur with left and/or right arrow head |
Date: |
Wed, 17 Apr 2019 21:33:30 +0200 |
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
- Slur with left and/or right arrow head, Lukas-Fabian Moser, 2019/04/15
- Re: Slur with left and/or right arrow head, Thomas Morley, 2019/04/17
- Re: Slur with left and/or right arrow head, David Kastrup, 2019/04/17
- Re: Slur with left and/or right arrow head, Thomas Morley, 2019/04/17
- Re: Slur with left and/or right arrow head, David Kastrup, 2019/04/17
- Re: Slur with left and/or right arrow head, Thomas Morley, 2019/04/17
- Re: Slur with left and/or right arrow head, David Kastrup, 2019/04/17
- Re: Slur with left and/or right arrow head, Thomas Morley, 2019/04/17
- Re: Slur with left and/or right arrow head, Aaron Hill, 2019/04/17