Re: Color tweaks (edition engraver)

[David Nalesnik]

Hi Joram,

On Mon, Apr 27, 2015 at 5:30 PM, Noeck <address@hidden> wrote:

Hi David,

thank you very much! This is great. It is by far enough for my purposes.
For an automatic option like in Frescobaldi it has some issues still –
as you describe.

> There is something which has to be fixed, though.  All clefs get colored,

Can this be avoided (even at the cost of not coloring them even if tweaked)?

Sure, but I wouldn't want to settle!

 

>  The best way to check, of
> course, is to run it with a large, heavily tweaked score.

That's my purpose, so I will give you feedback soon. The first
impression is that it colors too much (hairpins, dynamics and ranges of
note heads).

Make sure those aren't instances of \override rather than \once \override ...

 

> The reason for this is that 'after-line-breaking is often used
> for advanced tweaks

Out of curiosity, could you explain to me what after-line-breaking is
doing and why it is used so often for advanced tweaks?

It's described as a "dummy" property, so you can set it to various callbacks without worrying that you will overwrite something important.  (There are a certain few grobs--Hairpin is an example--which have default settings for this property, however..  To deal with that, I make sure that the default value of 'after-line-breaking is returned after I have made my changes to 'color.)

There are two such dummy properties distinguished by when they are called: before-line-breaking and after-line-breaking.  The timing can be crucial.  Let's say you want to change pieces of broken spanners.  You need to look for the pieces within 'after-line-breaking, because the spanner will still be whole when 'before-line-breaking is evaluated.

The issue with the current file is

(1) calling the music function adds a pair for after-line-breaking at the head of the properties alist;

(2) a user's advanced functions will add a pair for after-line-breaking as well

(3) we want to get rid of (1) when deciding whether to color, but we need (2) to be evaluated

This can be resolved, but I'm too tired to deal with it right now.

Hope this helps!

David

P.S.  I'm wondering if it would be cleaner to modify the music _expression_--that is, what is returned by \displayMusic, rather than the approach taken here.  I'll have a look.