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

[Carl D. Sorensen]

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.

Han-Wen,

You expressed concern about Chris's initial approach:

You should use get_property("stencil") unless you're doing something
special.  Still better is to use a callback in the spanner which
copies the stencil from its children.

Chris replied:

I originally tried get_property, but the result was that the spanned
arpeggio copied the exact stencil from the child arpeggio, resulting in
only part of the spanned arpeggio being drawn. It appears to me that
get_property causes the stencil callback to be executed (using the data
from the child arpeggio), while get_property_data got a reference the
callback, allowing it to be run later. I looked for documentation or
mailing list posts to figure out what was going on, but couldn't find
anything that explained to me the difference between the two functions.
Looking at the code in grob-property.cc, it appears to me that my
analysis is correct, but I wouldn't be surprised if I'm oversimplifying
things or just plain wrong.

The second option you gave does not appear to me to be possible without
changing the way that spanned arpeggios are constructed. Unless I'm
mistaken, spanned arpeggios are not aware of their children - the
Span_arpeggio_engraver steals the stems and side-support-elements from
the children and feeds them to the spanned arpeggio. It seems to me that
the strategy I implemented (stealing the stencil property from a child
and feeding it to the spanned arpeggio) fits this pattern.

I did realize that the ly_symbol2scm call was not needed. I've attached
a new patch that does not include it.

And the new patch is:

---
 lily/span-arpeggio-engraver.cc |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/lily/span-arpeggio-engraver.cc b/lily/span-arpeggio-engraver.cc
index 07958a8..9b5f0d6 100644
--- a/lily/span-arpeggio-engraver.cc
+++ b/lily/span-arpeggio-engraver.cc
@@ -61,6 +61,7 @@ Span_arpeggio_engraver::process_acknowledged ()
     {
       span_arpeggio_ = make_item ("Arpeggio", SCM_EOL);
       span_arpeggio_->set_property ("cross-staff", SCM_BOOL_T);
+      span_arpeggio_->set_property ("stencil",
arpeggios_[0]->get_property_data ("stencil"));
     }
 }

-- 
1.5.6.3


Han-Wen, do you have any objections to the new patch?


Thanks,

Carl