[Top][All Lists]

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

Re: Back in the Pond

From: David Kastrup
Subject: Re: Back in the Pond
Date: Fri, 20 Jan 2017 12:19:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

David Kastrup <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>> Alexander Kobel <address@hidden> 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

reply via email to

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