Re: Coloring of key signature accidentals based on their pitch

[Paul Morris]

Hi David,

On Aug 21, 2015, at 9:57 AM, David Nalesnik <address@hidden> wrote:

You're welcome.  Just for kicks, I've attached a .cc file which you could drop into the lily subdirectory and build.  It makes Line_interface::line available to Scheme. You'd just need to replace the two instances in the hairpin function with calls to ly:line-interface:line. So, lines 405-10 become

                 (set! mol (ly:line-interface::line grob x starth width endh))

                 (set! mol

                       (ly:stencil-add

                        mol

                        (ly:line-interface::line grob x (- starth) width (- endh))))

This enables drawing of the different line styles (dashed, zigzag, etc), based on overrides of Hairpin.  AFAICT this makes the Scheme stencil callback have all the same functionality as the C++ original.  So

\override Hairpin.style = #'zigzag

will work.

You can also override dash-definition, and the like.

  

(I will put this new line function forward as a patch for review when the system is over the upcoming bump.)

Nice!  It’s cool to see how you’re doing this kind of thing with a relatively simple example.

Seeing how you’ve done these is giving me some confidence that I might be able to do the same for the ledger line print function.

I looked at this briefly, enough to see that it will be more involved!  You'll need to track down the data structures used there and see if there's a convenient Scheme alternative  But pretty complicated things are possible--see the Scheme rewrite of the ambitus engraver in the snippets.

Yep, it still looks pretty daunting on closer inspection.  Seems like the ledger requests data structure stuff could be redone with some nested alists.  We’ll see.  Thanks for the tip on that ambitus snippet – it is impressive!  I hadn’t looked at it before.  

I made a “commented c++” version of your hairpin code.  This time I used somewhat larger blocks of code which works better than line by line.  I ended up also redoing the key signature file that way while I was at it — and made the paren correction.  Both attached.

Thanks!  The larger blocks of code are a good idea, especially when the translation becomes less line-for-line.  (I kept pretty literal in my adaptation, though.)

I found an error in the hairpin code rewrite--we need to exit the entire function when a bad grow-direction is found, so everything after line 44 needs to be a clause of the if-structure beginning in 41.  Simple removal of the parenthesis in 44 and addition of one at the end fixes this.  I went ahead and attached the correction with the indentation redone.  In this connection, I'm noticing is that it's easy to get very nested structures in Scheme when the C++ original exits at a number of points through returns.  Maybe there's an easy way to avoid this but I don't know of it.

Good catch, thanks!  The only thing I can think of to prevent this nesting is to split the function into separate functions and chain them together.  So you would either call the next function or “return early” without calling it.  All the needed data would be passed through as parameters.  Not sure if that’s a good approach (performance wise) or not.  On the one hand the additional functions aren’t even called in some cases, on the other hand you have more functions that get called when they are all needed.

Cheers,

-Paul