David Kastrup <d...@gnu.org> writes:
> David Kastrup <d...@gnu.org> writes:
>
>> Alexander Kobel <a-ko...@a-kobel.de> writes:
>>
>>> +1. A personal wish: I think that \lyricsto ChoirStaff = "ctx" {
>>> ... } has the potential to be a killer feature w.r.t. usability for
>>> choir literature (especially combined with the upcoming automatic
>>> extenders). Unfortunately, assignment of lyrics to *container*
>>> contexts does not work (at least, not reliably), and extender
>>> generation is completely defunct.
>>
>> Uh, I thought that people replaced extenders right now?
>>
>>> I reported that in a thread from 2016-12-26 on bug-lilypond, but could
>>> not motivate any supporters yet.
>>
>> The container context issue would want to be tackled by a melisma
>> translator (working both in Midi and PDF since we want the same results
>> there). That work is unfinished and somewhat pervasive. So it's a bit
>> unlikely for 2.20.
>
> I have to grudgingly admit though that picking up the pieces of the
> melisma translator would be rather more appropriate for 2.20 (as it
> wraps up half-finished functionality already in LilyPond) than working
> on arbitrary-precision support.
>
> Well, I'll have to take another look to see what got me stuck last time
> around.
Ugh, now I remember. The Melisma_translator needs to work reliably in
Midi. For this it needs to know where slurs start and end. But the
complex logic matching slur starts and ends based on spanner-id actually
is buried in the slur-engraver and works with actual spanners (some kind
of grob). Which means that its logic is just not accessible to the
Melisma_translator and would need to get duplicated.
That's where I ran into molasses.
Taking this up where I left it with a fresh mind now, I think that the
best course would be having a Spanner_connect_translator not working
with grobs/spanners but rather the originating events and tieing _those_
together based on values of spanner-id.
Great idea. Which would totally throw at least half a spanner in the
works of the (almost complete?) multiple-spanner GSoC project. Which
has already triggered (committed) changes in spanner-id user interfaces
and organisation but those would survive.
This sucks. I'll have to brood somewhat more over it.
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
