Re: triggering translation from engraver

[Jan-Peter Voigt]

Hi David,

thank you for your work on this! I will try/investigate it later this evening 
or tomorrow in the morning.

Best
Jan-Peter

Am 23. August 2017 18:33:15 MESZ schrieb David Kastrup <address@hidden>:
>David Kastrup <address@hidden> writes:
>
>> David Kastrup <address@hidden> writes:
>>
>>> Jan-Peter Voigt <address@hidden> writes:
>>>
>>>> Do you have another idea how to do that?
>>>
>>> Timing is established by iterators and they work on music
>expressions,
>>> not events.  So you need to have an iterator in the race from the
>start.
>>> Few iterators have variable length.  The sequential iterator can
>have an
>>> elements-callback delivering music expressions.  Those can have a
>>> structure and/or length determined at callback time.
>>>
>>> Kicking this into orderly operation does not seem like it would be
>>> reasonably workable.
>>>
>>> Iterators are not user-definable at the moment.  Either a general
>>> facility or a more specific "wait-iterator" would seem warranted.
>>
>> You might want to use \lyricsto to add your private control context
>to
>> the Score context.  When switching off everything that can track
>> melismata, you might get woken up once per event regardless of how
>long
>> your actual expressions are.
>>
>> But it might make more sense to work on actual infrastructure for
>this
>> rather than fudging around with existing facilities not intended for
>it.
>
>As an example: I've created a \waitFor music function that does
>something similar to what you want.  It was just quite useless in the
>original state since it waited for a particular expression, and you
>cannot use it to wait for \mark "B" when the mark has been generated
>with \mark \default .
>
>It turns out, looking at it, that the C++ code already does something
>more useful, namely taking the "procedure" callback for evaluating a
>triggering condition.  While the LilyPond code does not yet match the
>C++ code: so I probably gave up for some reason after noticing that
>this
>still wasn't what I could be using.
>
>So this definitely needs fleshing out into something more useful.  But
>it illustrates the kind of iterator you likely want to be using: I seem
>to remember that I was able to make the original version (before
>fudging
>the procedure callback into the C++ code) do something.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.