Am Sa., 23. Juli 2022 um 19:15 Uhr schrieb Jean Abou Samra <j...@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
