lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Direction operators in event-function


From: David Kastrup
Subject: Re: Direction operators in event-function
Date: Sun, 21 Oct 2018 16:58:52 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Urs Liska <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]