lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ChordNames in Staff context


From: David Kastrup
Subject: Re: ChordNames in Staff context
Date: Fri, 01 Nov 2013 18:27:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Robert Schmaus <address@hidden> writes:

> 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!

LilyPond can't support everything which people consider "a technique":
there are many things that work more by chance than anything else.

In this case, it was a _documented_ technique, however:
<URL:http://code.google.com/p/lilypond/issues/detail?id=3641>.  If you
find one of _those_ breaking, pointing out the respective part of the
documentation greatly increases your chance of getting a fix.

> 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.

Well, I'm playing the accordion.

> 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.)

The problem was not one of "code hygiene".  The problem was
<URL:http://code.google.com/p/lilypond/issues/detail?id=2990>: due to
improvements elsewhere, LilyPond simply crashed on your input while
eating all the memory.  The change made it spew error messages and
hobble on instead.  Not the best improvement, but better than a hard
crash.

> 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,

Not really...

> 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 ...

It's easy to to

\layout {
  \context {
    \ChordNames
    \name "ChordNamesInStaff"
    \alias ChordNames
    \remove "Axis_group_engraver"
  }
  \context {
    \Staff
    \accepts ChordNamesInStaff
  }
}

and then use \new ChordNamesInStaff whenever you want.  That will work
fine and also let you differentiate between the two (\new ChordNames
will automatically go outside of a Staff).

That's reasonably elegant.

What isn't elegant is the kind of stuff that occurs when you don't do
that.  It's not as bad as a hard crash, but not pretty either.

> 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 ...

Well, 2.17.96 will likely have that fix from issue 3641 (in about two
weeks), and 2.18.0 will likely follow suit.  Then your old scores should
at least not suffer from this problem.

This VerticalAxisGroup thing was actually on my "can't we do this more
sanely before 2.18?" list.

-- 
David Kastrup



reply via email to

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