lilypond-devel
[Top][All Lists]
Advanced

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

Re: triggering translation from engraver


From: David Kastrup
Subject: Re: triggering translation from engraver
Date: Wed, 23 Aug 2017 17:34:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

Jan-Peter Voigt <address@hidden> writes:

> Hi developers,
>
> I have difficulties to find the right words for this question, but I'll try:
>
> The edition-engraver comes into action, when it finds a mod
> (tweak/override) for the current spot in time, that is
> measure/barNumber and moment/measurePosition. These mods are applied
> in one of the engravers slots, that is either (most times) in the
> start-translation-timestep, acknowledger, listener or the
> process-music function.
> Now, if there is no stop/break in translation the function will not
> get called:
> \editionMod target 1 1/8 Voice \override ...
> will not get called if the music is something like
> { c'4 c' }
> because after step 0/4 step 1/4 will get called, but not the 1/8 step.
> (I hope you can follow)
>
> There are two things I'd like to accomplish:
> 1. allow the edition-engraver to apply tweaks outside the regular
> "stops" of the music
> 2. add an offset to a mod and apply the tweak a given moment after the
> current time
>
> To do that I would like to trigger/broadcast an event that forces the
> translator to stop again after a given moment has passed. The former
> example will work if I add some skips to the music:
> << { c'4 c' } { s8 s s s } >>
>
> But in my tests broadcasting a skip-event didn't show the desired
> effect. Maybe I did something wrong or maybe this is the wrong way.
>
> 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.

-- 
David Kastrup



reply via email to

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