On 15/11/2012 23:52, David Kastrup wrote: > Kieren MacMillan <kieren_macmil...@sympatico.ca> 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, reinh...@kainhofer.com, 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user