[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ChordNames in Staff context
From: |
Robert Schmaus |
Subject: |
ChordNames in Staff context |
Date: |
Sun, 13 Oct 2013 17:45:39 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 |
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
- ChordNames in Staff context,
Robert Schmaus <=