Urs Liska <li...@openlilylib.org> writes:
> Am 21.10.2018 um 16:58 schrieb David Kastrup:
>> 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.
>
> I see, this explains the observations.
It's also arguably a bug or at least a disservice (just because it's
straightforward to explain how behavior comes about does not make it
correct).
>>> 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.
>
> Somehow I was afraid I didn't express myself clearly enough :-(
>
>> What do you mean with
>> "explicit direction operator" here? What do you mean with "generated"
>> direction?
>
> With explicit I refer to a direction explicitly assigned, either
> thorugh ^/_ or an \override like \slurUp etc. If I call my function
> with ^\propagate-direction there is an explicit direction in place
> while the event-function is called, isn't it?
No. I have no idea how you think direction operators work. They don't
magically change the meaning of expressions such as
#{ -\markup #text #}
Expressions are evaluated from inside to outside, like with basically
every computer language implementing operators.
> If OTOH I call it with -\propagate-direction or without an operator
> the direction will only be generated/calculated at some later point,
> depending on the layout algorithms. Is that correct or am I missing
> something?
You are missing something. -postevent leaves postevent as-is,
^postevent sets it direction to #UP , _postevent sets it direction to
#DOWN . Before it can do anything with that postevent, the postevent
has to be _there_ in the first place, like it is when being returned by
an event function.
> What I would *like* to do is a function like
>
> propagate-direction =
> #(define-event-function (text)(markup?)
> #{
> -\tweak direction #UP
> -(
> -\tweak direction #UP
> -\markup #text
> #})
>
> but instead of hard-coding #UP I'd like to calculate the values based
> on something. For example let the text have the opposite direction of
> the slur and have the slur accept the ^\_ operator.
Even assuming PostEvents are fixed, you'd still be stuck having to look
at one event from another, independent one. You'd be missing a reliable
handle for that. You'd need to use an engraver for doing that kind of
interaction.
> From what I can understand this information *should* be present at
> that moment,
I have no idea what you mean with "that moment". There is no musical
moment while music is being input, that is only available when
iterating. And if you mean "that point of input processing" this is
nonsense since ^ and _ cannot affect an input expression before it has
been returned by the event function.
> while I'm aware that it is *not* possible to do the same relying on
> the automatically determined direction of the slur (which is only
> calculated later).
>
> Does that make my question clearer?
Not to me. The words you use do not make sense with regard how LilyPond
can be reasonably expected to process input. I just don't see any
viable connection between the handwaving expectations expressed therein
and any feasible manner of implementation. So when you use sort-of
technical terms, I have no idea how to map them to the actual things
happening.
>> 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.
Still the essence of my problem with your statements.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
