Re: Extending \lilypondfile to support separate handling of header fields for use by LaTeX et.al.

[Michael Haynie]

Looking at the code, It seems to me that this version will still force 
me to edit the tex output -- though I'm not certain (see below).  Have 
you had a chance to look at the example I sent, particularly the 
portion that rewrites the lilypondfile macro?

Unfortunately, that version doesn't work for me, on 2.6.4

Since there might be some 2.7 facilities in the code, here are the 
results of a run:

lilypond-macros -f latex --psfonts --process="lilypond -b eps -H title 
-H copyright" working.ltx
lilypond-macros (GNU LilyPond) 2.7.21
Reading working.ltx...
Running latex...
Dissecting...base.macros is up to date.

Traceback (most recent call last):
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1921, in ?
    main ()
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1887, in main
    chunks = do_file (file)
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1739, in do_file
    do_process_cmd (chunks, input_fullname)
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1595, in do_process_cmd
    write_file_map (all_lys, input_name)
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1582, in write_file_map
    snippet_map.write ('("%s.ly" . "%s:%d (%s.ly)")\n'
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1201, in basename
    return latex(self.n_basename())
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1207, in n_basename
    return 'lily-%d' % self.get_hash ()
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1196, in get_hash
    self.hash = abs (hash (self.full_ly ()))
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1043, in full_ly
    return self.compose_ly (s)
  File 
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros", 
line 1191, in compose_ly
    return (PREAMBLE_LY + body) % vars ()
TypeError: not enough arguments for format string
make: *** [working.tex] Error 1


On Jan 2, 2006, at 9:56 PM, Bernard Hurley wrote:

> Hi,
>
> I have not looked at you new stuff yet, but this might interest you
> Here is a newer version of "lilypond-macros".  You will obviously have
> to edit it as before to make it work with your version of lilypond. I
> have adapted your \lilyInputTexTitledExample macro to work in this
> environment. (The old version not the new one)
> Several files of macros of macros are generated:
>
> library.macros
> ==============
> One of these for each library of songs (see below). The macros are not
> designed to be used by the end user, but provide information for the
> other macros.
>
> base.macros
> ============
>
> This contains the following macros. [1]:
>
> \lilyHeader[library]{songname}{headername}
> \lilyInputSingle[library]{songname}{headername}
> \lilyInputRange[library]{songname}{start}{end}
> \lilyStyle{style}
> \lilyInputSystems[library]{songname}
> \lilyInputVerbatim[library]{songname}
> \lilyEPS{library}{songname}{system}
>
> _All_ header fields are accessible through \lilyHeader. This is true
> whether or not they are "official" lilypond headers.  [2]
>
> All songs are assigned a "songname". The user can assign this value by
> defining a "songname" header in a header block. The songname _must_ be
> alphabetic.
>
> All songs belong to a library this defaults to "default". (In all 
> macros
> except \lilyEPS, the library parameter is optional). A value can be
> assigned to this by defining a "library" header.
>
> The macros do more or less what you would expect. A couple of comments:
>
> \lilyStyle{style}
> -----------------
>
> This macro changes the behaviour of \lilyInputSystems. The following
> styles are currently available:
>
> default - This makes the generated tex code behave identically to code
> produced by lilpond-book
>
> info - prints "library" and "songname" before each song. This is useful
> if you want to use the macros in other LaTeX files as it provides an
> index of the songs.
>
> titled - This makes the behaviour similar to your
> \lilyInputTexTitledExample. The only difference is that if the lilypond
> code does not have any titling then all systems are included.
>
> striptitling - This causes the first .eps file to be ignored if it
> contains titling
>
> If you look in base.macros, you will see how to define more "styles"
>
> \lilyEPS
> --------
>
> In this macro the library parameter is _not_ optional. It is designed 
> to
> be non-fragile so it can be used with things like ps tricks. It
> evaluates to the name of an .eps file to include
>
> [1] Actually this file does not need to be generated, but it only gets
> written if it has changed and I find it easier to have all macros being
> generated in the same place.
>
> [2] Actually there is one exception - you cannot use "titling" as a
> header name - it will not be recognised. Also all header names _must_ 
> be
> alphabetic. If a header is defined twice, it is the second value that 
> is
> used.
>
>
> On Sun, 2006-01-01 at 13:12 -0500, Michael Haynie wrote:
> > I found and fixed two problems with the LaTeX macros I sent out
> > earlier, and revised the hymn song example format to move the 
> > copyright
> > text to the end of the song.  The fix for header processing is a 
> > little
> > ugly -- I think there must be a simpler way, but (a) it works, and (b)
> > it doesn't materially increase processing time, which is still
> > dominated by lilypond proper.
> >
> > I'm still pretty happy with the mechanism this represents, but for two
> > things.
> >
> > * -Hall to extract every header would be would be tremendously useful.
> > Otherwise, I have to extract all of the headers individually, and
> > that's *really* tedious.
> >
> > * markup in header text is not handled well at all.  I'm really not
> > certain how to proceed -- the lilypond markup doesn't look much like
> > the equivalent LaTeX markup, though some type of parser should be able
> > to translate from one form to the other.  It would be easy to write
> > such a filter in C/C++, but that would introduce yet another language
> > into the mix.  Not a happy thought.  A top-down parser could be
> > hand-written, I suppose.
> >
> > As before, comments are welcome.
> >
> >
> >
> > On Dec 29, 2005, at 8:08 AM, Bernard Hurley wrote:
> >
> > > Hi Michael,
> > >
> > > On Tue, 2005-12-27 at 16:45 -0500, Michael Haynie wrote:
> > > > I had a good look at the proposed alternative mechanism as described
> > > > in
> > > > lilypondmacros.  It mostly worked, but left me with a fair amount of
> > > > hand editing that would have to be revisited each time I rearranged
> > > > the
> > > > songs in the book -- a *frequent* occurrence when I'm laying out a
> > > > book
> > > > for final printing.  I studied what you did, and I've developed an
> > > > alternative suggestion, in several parts:
> > >
> > > I've been fixing some of the bugs in my code (there were some really
> > > silly ones like getting the system count wrong) and changing the way 
> > > it
> > > works. I will send you a new version soon.  I will also have a look 
> > > at
> > > you ideas which look interesting and see how I can take them into
> > > account. But that will have to be after 3rd Jan as I have a lot of 
> > > work
> > > to do by then. Just one thing, since I will be realeasing by stuff
> > > under
> > > GPL 2 or later, could you confirm that your files can be released 
> > > uner
> > > this license?
> > >
> > > Regards,
> > >
> > > Bernard
> --
> Bernard Hurley <address@hidden>
> <lilypond-macros>