(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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
