lilypond-user
[Top][All Lists]
Advanced

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

Re: Ties between voices


From: Thomas Morley
Subject: Re: Ties between voices
Date: Tue, 26 Jul 2022 11:48:57 +0200

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

Attachment: tie-engraver.cropped.png
Description: PNG image


reply via email to

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