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

[Chris Snyder]

(a caveat to the following message: I'm still learning how the LilyPond
code is organized - please gently correct me when necessary)

Joe Neeman wrote:
> 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.

The issue for me with this approach is that the NR instructs the reader
to use the \arpeggioXx macros. I think your initial suggestion was to do
the overrides at the Score.Arpeggio level instead of the
PianoStaff.Arpeggio level. Modifying the macros to either of those
approaches produces issues, however: Score-wide leads to potential
issues with much bigger scores (such as orchestral scores), while
modifying it at the PianoStaff level makes the macros not work in any
non-PianoStaffs (at least I assume that would be the case - I haven't
tested it).

> 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.

That is true. I'm guessing, though, that most users - even moderately
advanced ones (the category I would describe myself as being in) - don't
even think to use \override commands in this case, since the NR gives
instructions for using the very convenient \arpeggioXx macros. The
current caveat in the NR (1.3.3: "The parenthesis-style arpeggio
brackets do not work for cross-staff arpeggios.") could be changed to
instruct users to use \override commands rather than the macros.

> 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?

I agree that Han-Wen's approach is better from an architectural
standpoint. I'd be willing to undertake such an endeavor if everyone
agrees that it would be desirable, as long as no-one minds the
occasional possibly-inane question on -devel. I think the problem you
mention with both approaches (which I did recognize when I was making
the patch) is a non-issue - LilyPond should not be expected to produce
sensible output from non-sensible input, such as a spanned arpeggio
comprised of arpeggios of different styles. I think that throwing up a
warning would be the most desirable outcome.

Thanks.

-Chris