Re: Ties between voices

[Thomas Morley]

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?

@ 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: Text Data