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