Urs Liska <li...@openlilylib.org> writes:
> But if I simply create two elements in the event-function the explicit
> direction operator takes no effect:
>
> propagate-direction =
> #(define-event-function (text)(markup?)
> #{
> -(
> -\markup #text
> #})
>
> {
> g'1 ^\propagate-direction "Up" g' )
> }
>
> (here both the slur and the text are printed below the staff.
>
> Why is that?
Multiple post events in one post event expression are temporarily
wrapped in one PostEvents music event. This is then what gets the
up/down direction. When it is unwrapped in use, the direction gets
lost.
Arguably, dissolving a PostEvents into separate events should try
applying some fields (tweaks, color, direction?). Unfortunately, there
are a lot. Alternatively, directions and tweaks should bypass
PostEvents and go through the enclosed events. Either would have some
performance impact. Maybe just walk the property list of a PostEvents
and copy _everything_ found there?
> And more importantly: how can I achieve the goal of creating more than
> one element in an event-function and still have the explicit
> directions from the calling code be applied?
>
> And why can't I access the explicit direction operator from within the
> event-function? I understand that the *generated* direction isn't
> accessible at that moment, but an explicit setting should be known at
> that point, isn't it?
I have no idea what you are talking about. What do you mean with
"explicit direction operator" here? What do you mean with "generated"
direction? The only direction operator I see here is clearly applied
_after_ calling the event function. It cannot magically affect
expressions you create inside of the function before the function even
returns.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
