[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
- Re: Back in the Pond, (continued)
- Re: Back in the Pond, Gianmaria Lari, 2017/01/19
- Re: Back in the Pond, Alexander Kobel, 2017/01/19
- Re: Back in the Pond, David Kastrup, 2017/01/20
- Re: Back in the Pond, Knut Petersen, 2017/01/20
- Re: Back in the Pond, David Kastrup, 2017/01/20
- Re: Back in the Pond, Knut Petersen, 2017/01/20
- Re: Back in the Pond, Alexander Kobel, 2017/01/20
- Re: Back in the Pond, Alexander Kobel, 2017/01/20
- Re: Back in the Pond, David Kastrup, 2017/01/20
- Re: Back in the Pond,
David Kastrup <=