Re: Ties between voices

[Jean Abou Samra]

> Le 27 juil. 2022 à 10:41, Thomas Morley <thomasmorley65@gmail.com> a écrit :
> 
> Am Di., 26. Juli 2022 um 11:48 Uhr schrieb Thomas Morley
> <thomasmorley65@gmail.com>:
>> 
>>> Am Sa., 23. Juli 2022 um 19:15 Uhr schrieb Jean Abou Samra 
>>> <jean@abou-samra.fr>:
>>> 
>>> 
>>> 
>>> Le 23/07/2022 à 12:49, Lukas-Fabian Moser a écrit :
>>>> 
>>>> Hi Andrew,
>>>> 
>>>> Am 23.07.22 um 03:49 schrieb Andrew Bernard:
>>>>> I know that we can't natively make ties between notes in different
>>>>> voices. I know that there was a Google Summer of Code task that could
>>>>> not be completed.
>>>> 
>>>> A few weeks ago, I sent you the following privately (I was too timid
>>>> to post in on the list):
>>>> 
>>>> My idea was to \consist the Tie_engraver to the Staff context not
>>>> _instead_ of to the Voice context, but _in addition_. Then we have two
>>>> Tie engravers and need a mechanism by which to tell if a given tie
>>>> should be collected by the Voice-level Tie_engraver or at Staff level
>>>> (in order to connect ties between different voices).
>>>> 
>>>> During my experiments I re-implemented the Tie_engraver in Scheme;
>>>> although it turned out that (contrary to my expectations) the
>>>> necessary adjustments could just as easily have been made in C++, the
>>>> advantage is that we can test this approach without the need to
>>>> re-compile a custom LilyPond build.
>>>> 
>>>> The attached file (requiring 2.23.6 and above) generates
>>>> 
>>>> 
>>>> as easily as:
>>>> 
>>>> \new Staff \with { \consists #New_tie_engraver }
>>>> {
>>>>  <<
>>>>    \relative {
>>>>      <c''~ c,\to Staff~>4 c8 b a g~ 4
>>>>    }
>>>>    \\
>>>>    \relative {
>>>>      s4 c'2 e4
>>>>    }
>>>>>> 
>>>> }
>>>> 
>>>> Of course the same mechanism might be implemented for, e.g., the
>>>> Slur_engraver. But this requires additional work, as the slur
>>>> positioning mechanism is not quite up to positioning Staff-level slurs
>>>> correctly.
>>>> 
>>>> The attached Scheme Tie_engraver may be used as a drop-in replacement
>>>> for the standard C++ Tie_engraver; in my local branch, it compiles the
>>>> full regression test suite without causing differences.)
>>>> 
>>> 
>>> 
>>> 
>>> Interesting, Lukas! Now, this approach fails on cases where
>>> ties are physically but not mentally interrupted, as pianists
>>> sometimes encounter, like
>>> 
>>> \version "2.23.10"
>>> 
>>> \new Staff <<
>>>   \relative {
>>>     <%{ tie this %} c' c'>2
>>>     c'8 b a g
>>>   }
>>>   \\
>>>   \relative { s2 %{ to this %} c'4 g }
>>>   \\
>>>   \relative { g16 a c d e a g e f4 d }
>>>>> 
>>> 
>>> but this might be rare enough that not catering for it
>>> would be good enough?
>> 
>> To make it visible, Jean's example, with Lukas' coding reads:
>> 
>> \new Staff \with { \consists #New_tie_engraver }
>> <<
>>   \relative {
>>     <%{ tie this %} c'\to Staff ~ c'>2
>>     c'8 b a g
>>   }
>>   \\
>>   \relative { s2 %{ to this %} c'4 g }
>>   \\
>>   \relative { g16 a c d e a g e f4 d }
>>>> 
>> 
>> and gives the attached output.
>> 
>> We probably need something like NoteColumn.tie-skip similar to 
>> 'glissando-skip.
>> Though, why not something more general like 'spanner-skip for all
>> spanners (usually) terminated at following NoteColumn?
>> 
>> @Lukas
>> You use hash-tables in your rewrite of the engraver.
>> Does the C++-engraver do so?
>> From a users point of view hash-tables are always inconvenient, imho.
>> Is the performance advantage really as huge not to use more simple alists?
>> 
>> Many thanks for your work!
>> 
>> Cheers,
>>  Harm
> 
> @ Jean
> I've got your last mail off-list. By accident?



Yes, sorry. To make it shorter, I was just saying that you could select the end 
note of the tie not as the first note with the right pitch that comes, but the 
first with the right pitch _and after the end of the tied note_, which would do 
the Right Thing automatically in the example being discussed.

Also, on further thinking it’s probably a bad idea to let \to broadcast the 
event only in one context, as other engravers might need it as well (eg 
Accidental_engraver). Refining this idea, in the same fashion as the recently 
added "once" listener feature (which I just made available to Scheme, it 
existed in C++ for a long time), we could have

(listeners
 ((event-class engraver event #:exclusive)
   …))

where #:exclusive means it’s not triggered if the engraver is not in the 
context adressed by \to (or some default context, probably specified in a 
property?).

Cheers,
Jean




> @ Lukas
> I have not yet understood all subtleties of your engraver code.
> Though, as a proof of concept I implemented a possibility to select
> and skip NoteHeads which should not be considered for ending a Tie.
> See attachment.
> 
> I stumbled across a certain condition. In tie-column::add_tie there is
>              (> (car (ly:grob-spanned-column-rank-interval tie-column))
>                 (car (ly:grob-spanned-column-rank-interval tie-column)))
> How could this ever be true?
> 
> Cheers,
>  Harm

tie-engraver-02-skip.ly
Description: Binary data