Re: parser placement problem [was Re: Lyrics disappear with associatedVoice in a duet]

[Reinhold Kainhofer]

On 15/11/2012 23:52, David Kastrup wrote:
> Kieren MacMillan <address@hidden> writes:
>
>> Hello all,
>>
>>>> I can get the voice switch to work by (a) reading the NR, where it says 
>>>> "\set associatedVoice = "two" % must be set one syllable early"
>> Is there any way we can fix all of the places where "the tweak must
>> come one moment earlier than the effect is desired", so that
>> everything can be coded "at the right time"?
> I think one will likely have to do this on a case-by-case basis.  I
> don't see that there would be some magical button that could fix every
> problem (or even an unrelated subset) at once.

The problem of the "one timestep earlier"  cases is that they usually
modify a dispatcher to send the events to a different context. Now, the
\set is evaluated at the same timestep as the following note, so when it
is processed, the following (note/lyrics/..) event was already
dispatched to one particular context (and thus changing the output
context will only affect all later timesteps).

So basically there are some separate parts to these issues:
1) the \set is evaluated together with the following note (timestep). As
a user, when writing lilypond code, I rather think of \set and \override
as something that is between notes. Lilypond (which is moment-based)
currently does not have that concept of something between timesteps
(that's also the problem that causes grace notes to mess up e.g.
clef/timesignature changes unless the grace notes are in all voices).

2)  Many thinks in lilypond "magically" work by simply  dispatching
events to the correct context. This is an amazing strategy, which makes
many thinks incredibly simple (e.g. the part-combiner: it does not
manually create chords or so, it simply has four voices and depending on
whether the notes can be combined or not, simply dispatches the events
to two of them. If they are dispatched to the same voice, you'll get
chords automatically.).

3) However, once the events are dispatched, there is no going back to
sending them to different contexts. In particular, there is no easy way
to redirect the remaining events dispatched to one context to a
different context (because you usually don't have a pointer to that
other context in the context that processes the event that changes the
dispatcher), once the dispatching happened. In most cases, that would
just be a workaround, anyway, and complicate the code a lot.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, address@hidden, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com