[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ChordNames in Staff context
From: |
Robert Schmaus |
Subject: |
Re: ChordNames in Staff context |
Date: |
Mon, 14 Oct 2013 20:53:50 +0200 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 |
Hi Keith,
thanks for your reply!
May I ask what the reasons were for
removing that technique?
Probably, no-one watching the changes knew that this was a technique.
that would be a pity!
From the email you linked, I can see the potential for a problem. The
Axis_group_engraver in ChordNames does the job of arranging all the
within the context into rows on the page. But if ChordNames is inside
a Staff, the Staff also has an Axis_group_engraver also trying to do
the same job, also collecting the same chord names into rows.
yes, I've understood basically the same (although I don't really know
about those engravers).
let me reply to that, that whatever the internal conflict was which the
removal of that technique tried to solve, the actual result of having
Staff accept ChordNames was quite outstanding. all musicians who I play
with always were in awe about the quality of my lead sheets (although I
could get hardly one to use lilypond as well as the text-based input
appears too outlandish to them).
my impression from following the lily-mailing list for some time (years,
actually) now is that the vast majority of users is concerned with
classical music only. also, David Kastrup's quote in my OP seems to
indicate that putting chord names right inside the staff is (in his
experience) not a plausible thing to do in music in general.
I assume therefore that not many lilypond-users actually do this and
that the reason for removing this technique was a matter of "code
hygiene" rather than actual engraving problems. (Please forgive me if
I'm wrong - I don't know about the internals of lilypond.)
that assumption is backed by (I can't stress this enough) the fact that
the results really were fantastic, and the code for achieving this
result was incredibly elegant, easy, not to mention intuitive, and the
compiling process/time (very short scores, admittedly) hinted at no
problems at all. so, there really was no reason for me to assume that
this possibility was a candidate for removal ...
<<
\new ChordNames \chordmode { s1*3 ges4 bes1:m7 }
\new Staff \with {\accepts ChordNames } <<
\new ChordNames \with {
\override ChordName #'Y-offset = #-1
\remove Axis_group_engraver
} { \chordmode {
\repeat percent 4 ces4 f2:m7.3-.5- bes:m7 es:m7 aes:m7
s1*2 } }
\new Voice {
\key es\minor s1*3
\transpose c c' {bes,4 des ges bes \chordmode { bes,1:m7 } } } >> >>
<<
\new ChordNames \chordmode { s1*3 ges4 bes1:m7 }
\new Staff <<
\new Voice \with {
\consists Chord_name_engraver
\override ChordName #'Y-offset = #-1
\remove Note_heads_engraver
} { \chordmode {
\repeat percent 4 ces4 f2:m7.3-.5- bes:m7 es:m7 aes:m7
s1*2 } }
\new Voice {
\key es\minor s1*3
\transpose c c' {bes,4 des ges bes \chordmode { bes,1:m7 } } } >> >>
thank you also for your solutions. I shall try them out - at first
glance and playing around a bit, I'm not sure if I can use them without
doing a lot of re-coding in my old scores. I guess I'll rather revert
back to 2.16 instead of doing that ...
thanks again & cheers,
robert