Robert Schmaus <[email protected]> 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
