lilypond-user
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]