#4098 Create a Syllable_translator

[Anonymous]

Originally created by: *anonymous

Originally created by: dak@gnu.org
Originally owned by: dak@gnu.org

This translator will listen for note events, beam events, tie events, slur events, check out the various melisma* context variables and will create synthetic "syllable" events.  While it would seem nice to provide spanners (namely with spanner-direction START and STOP) for flexibility, stuff like dangling ties and tieWaitForNote make it unclear whether one can hope to do that reliably, to a degree where a syllable-stop event can only occur too late in situations where we warn about unfinished ties etc anyway.

Everything having to do with lyric synchronization will listen exclusively to syllable events.  Listening to NoteColumn grobs etc might still be desirable for graphic alignment purposes, but the respective engravers should be robust about not getting to see any.

This will make it possible to reliably synchronize lyrics to whole Staff environments (as issue 4097 implements but without being able to offer coherent melisma processing, something which would fall out painlessly as a side effect of having a Syllable_translator) processing a Lyric syllable whenever one of the contained voices starts a syllable.  It will also make all syllabic synchronization work identically across \layout, \midi, and whatever may be there to come.

It will greatly simplify the jiggery-pokery currently involved with the NullVoice context (causing the current impasse for issue 4093), even though NullVoice itself will lose much of its appeal with a reliably working version of issue 4097.

[Google Importer]

Originally posted by: janek.li...@gmail.com

Looks nice!  Have you already started working on this?

[Google Importer]

Originally posted by: dak@gnu.org

Yes.  There are basically two possible approaches: send a SyllableEvent with a span-direction of START for syllable starts, of CENTER for melismata, and of STOP when a syllable ends (the latter is probably not needed currently).  The advantage of using events would be that associating with some non-bottom context will still deliver suitable information.  The disadvantage is that if you connect to such a context mid-syllable or if you do not actually want to connect at all, the information is not there.

Now the melisma information itself is stored in
melismaBusy slurMelismaBusy tieMelismaBusy beamMelismaBusy completionBusy
already which is an awful lot of properties to check for quite a few Lyric and which also take some time writing.  It would be possible to add a "noteBusy" to it easily.  However, it does not buy all that much since the lyric engravers still need access to the actual note grobs of an associated context for graphical alignment.

So for Lyric synchronization I'll need to use the same voice association mechanism used in Lyric_combine_music_iterator also in Lyric_engraver.

Which is somewhat sketchy since, say, in Lyric_engraver, there is an undocumented context property searchForVoice which will, when set, cause a Lyric context named "soprano-I-lyrics" to attach to a voice named "soprano-I" if associatedVoice is not set.

Who knows who relies on which historic interaction.  It would also appear that the voice searching mechanism in the Lyric_engraver is in competition with the Lyric_combine_iterator since the Lyric_combine_iterator will use the Lyric_engraver for engraving its lyrics.

So at any rate figuring out which information should be where at which point of time is turning out to be a bit messy.  Because the mess is already there.