Am Mi., 17. Apr. 2019 um 10:13 Uhr schrieb Lukas-Fabian Moser <l...@gmx.de>:
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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
