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?
Amusingly, I was thinking about pretty much the same concept
yesterday, but in a completely different context and without
cross-staff spanners in mind. I was musing about contributing
a "highlight" feature to colorize a music passage, and how
highlighting different contexts, like a full StaffGroup
or just a Staff, would be handled internally. I thought
that the engraver could refrain from handling an event
if it detected that context the event wanted to highlight
(stored in an event property) was not matching the engraver's
context, but I wondered if it could be more general, which
leads to thinking about your \to command being implemented
as
to =
#(define-music-function (ctx mus) (symbol? ly:music?)
(make-music 'ContextExclusiveMusic 'target ctx 'element mus))
where ContextExclusiveMusic would be recognized by
Music_iterator::report_event (see find_above_by_music_type)
to make any event within ContextExclusiveMusic only
broadcast in engravers of the context addressed by \to.
Just in case that helps you further your idea ...
Cheers,
Jean
