lilypond-devel
[Top][All Lists]
Advanced

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

Re: PATCH: Allow setting of arpeggio type for spanned arpeggios


From: Joe Neeman
Subject: Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Date: Thu, 22 Jan 2009 18:25:13 -0800

On Thu, 2009-01-22 at 08:06 -0700, Carl D. Sorensen wrote:
> Graham asked me to take this patch on as part of my FrogMeister duties, so
> here goes.
> 
> Chris,
> 
> Can you make a brief regression test that shows why this patch is desirable?
> Joe seems to feel like it's unnecessary, because you can set the
> span-arpeggio style by setting Score.Arpeggio #'stencil.
> 
> 
> Anybody on devel,
> 
> If we use Joe's approach, there would be one type of Arpeggio for the whole
> score, at least at any music moment.  Is there a reason why somebody would
> want to have different arpeggio stencils for different staffs?   If so, then
> I think Chris's solution is better than Joe's.  If not, then I think we
> ought to change the predefined arpeggio commands to work on Score.

My approach can work at the same granularity as \set connectArpeggios.
That is, if the Span_arpeggio_engraver is at the PianoStaff level (which
it is by default) then you can override PianoStaff.Arpeggio #'stencil to
affect only the Arpeggios in that PianoStaff.

I should probably explain my objection to the original approach: every
time we set a user-overrideable variable in an engraver, we make it
impossible for the user to set that variable directly. What's more,
there is no indication in the automatically-generated docs that the
user's override would be ignored. Maybe it's a contrived example, but if
someone does

\override Voice.Arpeggio #'stencil = #foo
\override PianoStaff.Arpeggio #'stencil = #bar

then they might wonder why the spanned arpeggio has a "foo" stencil even
though it is created in the PianoStaff context.

I think Han-Wen's approach is the "real" solution, but it's also a bit
more work. You could create a new SpanArpeggio grob that gets Arpeggios
as children and has, as default properties, callbacks that check the
children. You need to decide what happens, though (this is also an
admittedly pretty negligible problem with Chris's original patch) if two
"child" arpeggios have different stencils: what happens to the span
arpeggio?

Joe






reply via email to

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