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

[Chris Snyder]

Carl D. Sorensen wrote:
> 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.

Well, I put together a regression test, but it's not exactly "brief" (I
demonstrated all of the approaches).

The files are here:
http://temp.mvpsoft.com/ly/arpeggios/

There are four tests:

arpeggio-1.png: Using standard \arpeggioXx commands (without the patch)
[*] arpeggio-2.png: Joe's idea
arpeggio-3.png: Joe's idea extended to actually modifying the
                \arpeggioXx commands
[*] arpeggio-new.png: the first test again with my patch applied.

The starred versions were rendered flawlessly. Joe's way, however,
required some non-intuitive \revert commands, as \arpeggioXx had no
effect after the \override Score.Arpeggio commands, even if they were in
different staves.

Explanation of desired output:

First chord: Connected, normal
Second chord: Connected, bracket
Third chord: Unconnected, top bracket, bottom normal
Fourth chord: Unconnected, top slur, bottom arrow-up

> Is there a reason why somebody would want to have different arpeggio
> stencils for different staffs? If not, then I think we ought to change
> the predefined arpeggio commands to work on Score.

Two possibilities: organ music (which I engrave a lot of) could require
such a situation; even more likely is in orchestral music, where there
are often a lot of independent parts. Those possibilities, plus the
possibility that existing scores could be broken, suggests to me that
modifying the \arpeggioXx commands is the least desirable approach.

Given the minimal invasiveness of my patch, it seems to me that even the
slight possibility of someone needing this functionality should support
its inclusion. My patch also makes LilyPond handle connected arpeggios
in an intuitive way (to me, at least), negating the need to add caveats
in the documentation.

I understand, however, the reason for your thoroughness in evaluating
patches, and I appreciate the excellent-quality code that results.

Thanks for your time.

-Chris