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