lilypond-user
[Top][All Lists]
Advanced

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

Re: adding to the LSR


From: Carl D. Sorensen
Subject: Re: adding to the LSR
Date: Tue, 28 Apr 2009 15:58:49 -0600



On 4/28/09 10:24 AM, "Jonathan Kulp" <address@hidden> wrote:

> Chip wrote:
>>> There are plans to upgrade it to 2.12 but it hasn't happened yet.  I
>>> don't understand all of the technical issues but one of the problems
>>> was discussed on a recent thread, which is that someone has to check
>>> all the snippets to make sure they compile under 2.12.  I might be
>>> doing some of this soon but haven't started in earnest.
>>> 
>>> Jon
>> If you need some assistance let me know, I have some time available as
>> I'm not working right now (yep, I'm one of the bazillions of unemployed).
>> --
>> Chip
>> 
> 
> Thanks for the offer, Chip.  I've just finished a preliminary run
> through all of the snippets.  I downloaded the tarball of the entire
> repo and ran them through the convert-ly script, then did a looping
> script that ran lilypond on each updated snippet using 2.12.2 and saved
> the terminal output for each in a text file.

Cool -- I didn't know you were up enough on scripting to do that kind of
work!  I think such a script should be added to scripts/auxiliar so that we
have it to use the next time we want to do an update.  (And you just
demonstrated that you have two of Larry Wall's attributes of a good
programmer: laziness and hubris.  Good for you!)

> 
> The results were pretty good, really.  About 95% of the snippets
> compiled and look the same as they did in 2.10.  Two snippets didn't
> compile at all, but I've already taken care of one of them
> (adding-octaves-automatically) because I've had to fix that one on some
> of my own files before.  The convert-ly script took the \octaves command
> as if it were an octave check instead of a user-defined macro.  I've
> changed the \octaves command in the original LSR code to \makeOctaves,
> which will survive the convert-ly update intact.

This probably also indicates a need to change the convert-ly rule for
\octave.  If it doesn't work for \octaves, it also wouldn't work for
\octaveAdjustFunction, or some other user-defined variable that starts with
\octave.  This should be either fixed or added to the issue tracker to get
fixed.

> 
> If you'd like to have a go with a few, try fixing the
> "changing-the-font-to-smallcaps", which doesn't even work in 2.10 in the
> snippet currently in LSR.  The font doesn't change at all.
> 
> Another one that doesn't work in 2.12 is
> "polymetric-section--synchronizing..."
> 
> It has a bunch of \InnerStaffGroup commands that must be obsolete
> because they're causing errors.  Changing these to \StaffGroup makes it
> compile, but then the staffgroup loses the bracket and it doesn't look
> right.  If you'd like to fiddle with that code until it works properly
> in 2.12 that'd be great.  (the authors of the snippet are given as John
> Mandereau, Reinhold Kainhofer, but these guys usually have bigger fish
> to fry than snippets in the LSR :) )
> 
> Others:
> 
> "setting-control-points-of-slur-manually" compiles but the slur runs
> right through some of the notes.  This doesn't happen in 2.10 but it
> does in 2.12.
> 
> "broken-crescendo-hairpin"--compiles but the hairpin doesn't break anymore
> 
> "positioning-segno-and-coda-without-line-break"--compiles but objects
> are colliding
> 
> There are probably more but I have to do some of my official work now. :)

There are also some snippets that work but should be changed to reflect
changes in 2.12.  I know of two snippets that have to do with lead sheets
(Chords, Fret Diagrams, melody, and lyrics) that should be changed to use
\predefinedFretboards and a FretBoards context, instead of using \markup
\fret-diagram.

I'm not sure if there are others.  There may be one related to auto-beaming.
I'm not sure what a good process on this is, but I think at a minimum, we
should look at NEWS for 2.12 and see if there are any NEWS items related to
each of the snippets.

That's why I estimated 15 minutes per snippet (I wasn't thinking of
automation, which I should have).  We should check each of the snippets and
see if the snippet is made obsolete or should be changed to reflect new
features added, not just check to see if the syntax is right.

Thanks,

Carl





reply via email to

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