ChordNames in Staff context

[Robert Schmaus]

Hello Ponderers,

I moved from Lily 2.16 to 2.17.25 recently. Some days ago, I had to 
recompile one of my scores from the pre-2.17 era (and I should probably 
mention that I almost exclusively write jazz scores, i.e. "lead sheets".

The compiling resulted in hundreds of errors (after applying 
convert-ly). It took some time to figure out, that the problem was the 
statement

\context {
    \Staff
    \accepts "ChordNames"
}

in the score block. A google search turned up this conversation from 
March 2013 which took place on the lilypond-bugs list:
http://lilypond.1069038.n5.nabble.com/programming-error-while-inserting-quot-ChordNames-quot-in-quot-Staff-quot-td143559.html

In his first reply to the OP, David Kastrup asks the question "Why would 
you want to have "ChordNames" internal to a Staff?"

I would like to give an answer to that: because that is a rather common 
notation practice with jazz lead sheets, appearing e.g. in the following 
situations:

- the solo chords differ from the chords used in the theme
- the theme actually *contains* passages which are without melody (eg 
for free soloing within the theme)
- the theme chord progression contains "as written" passages

I can provide examples for all of those cases (and maybe there are more 
cases) but if I attached them, the mail would get too large (>100K) and 
not get through ... but I can attach one ...

needless to say that I used that technique extensively in my scores, and 
I would be rather sad to see it die. May I ask what the reasons were for 
removing that technique?

On that discussion on the lilypond-bug list, a solution

\layout {
   \context {
     \ChordNames
     \remove "Axis_group_engraver"
   }
}

is mentioned. that solution works well for the chords which are inside a 
Staff context, but it ruins the chord layout which is inside the 
ChordNames context itself. so that's no solution, really.
are there any suggestions how the old behaviour can easily be restored? 
I'd rather avoid complicated scheme solutions (I couldn't produce those 
anyway) which will probably be rather sensitive to all sorts of 
things/changes in lp etc ...


hoping for the best,
Robert

Screen Shot 2013-10-13 at 5.44.42 PM.png
Description: PNG image