[Top][All Lists]

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

Re: triggering translation from engraver

From: Jan-Peter Voigt
Subject: Re: triggering translation from engraver
Date: Wed, 23 Aug 2017 19:04:43 +0200
User-agent: K-9 Mail for Android

Hi David,

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


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
>>> not events.  So you need to have an iterator in the race from the
>>> 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
>> the Score context.  When switching off everything that can track
>> melismata, you might get woken up once per event regardless of how
>> your actual expressions are.
>> But it might make more sense to work on actual infrastructure for
>> rather than fudging around with existing facilities not intended for
>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
>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
>the procedure callback into the C++ code) do something.

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

reply via email to

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