extending \lilypondfile was: Re: Extracting header fields for use by e.g. LaTeX?

[Bernard Hurley]

Hi,

This discussion, started on the "user" list. However it now seems more
appropriate for the "developer". We started discussing how header fields
might be used in lilypond-book and got on to discussing a possible
extension to \lilypondfile, with an optional extra parameter (As in
\lilypondfile[mysong{song.ly}). It should be possible for anyone
interested to pick it up from here.

On Wed, 2005-11-30 at 23:28 -0500, Michael Haynie wrote:
> Interesting.  Very clean from a compatibility point-of-view.
> 
> I guess lilypondfile would call a macro if was defined, and include 
> everything otherwise? Maybe \includeLilypondSystems{}
> 

\lilypondfile isn't actually a LaTeX macro but is used by lilypond-book
to generate LaTeX code. lilypond-book generates LaTeX code:

        \input lily-xxxxxxxxxx-systems.tex.  

This file in turn is generated by scheme code "framework-eps.scm" and
contains the LaTeX code to include the lily-xxxxxxxxxx-n.eps files in
the correct order. 

The way I had thought of implementing the extension includes modifying
the scheme code so that lily-xxxxxxxxxx-systems.tex behaves differently
when the extended \lilypondfile is used.

However a better way would be (and actually easier to implement!):

        IF \lilpondfile has no extra parameter:
                lilypond-book acts as before and generates the \input...
                and framework-eps.scm acts as before

        OTHERWISE:
                lilypond-book generates the definitions of
"referenceBase" etc.
                (or modifications of them I suggest below) and does
_not_
                generate the \input... however framework-eps.scm still
                generates lily-xxxxxxxxxx-systems.tex

Then it would then be comparatively easy to write an
\includeLilypondSystems{} macro so that:

        \lilypondfile[mysong]{song.ly}
        \includeLilypondSystems{mysong}

would have the same effect as:

        \lilypondfile{song.ly}

The difference is that a macro could be written that, for instance
includes a lilyheader so you could, for instance, write:

        \lilypondfile[mysong]{song.ly}
        \section{\lilyheader{mysong, title}}
        \includeLilypondSystems{mysong}
        
(I am assuming that -H title has been used for the lilypond call of
course)

It would also mean that I would not have to touch framework-eps.scm
although it might still be a good idea to modify it a little as it would
be more robust if the code that wraps the
        \input lily-xxxxxxxxxx-systems.tex
was generated by framework-eps.scm instead of directly by lilypond-book.

> Many users might have no idea how to define the macro to include a 
> sequence of generated files.
> 

Many users would not be able to define the \lilyheader macro either, and
you could probably think of other useful macros. For instance to get the
first system you might do:
        \includeLilypondSystems[1]{mysong}

\referenceBase, \referenceCount, and \referenceFile would be better as
\lilybase{reference} etc. - this is neater and does not clutter up the
LaTeX macro namespace. (It would still be possible to implement the code
as suggested above but lilypond-book would have to generate defintions
of "internal" names e.g. address@hidden instead of referenceBase -this
would then be picked up by \lilybase)

In order not to break any existing code I would suggest these macros are
defined in a file that is only \input if the extended version of
\lilypondfile is ever used. That is very easy to implement. 

> We should provide a macro for the default case (include everything,
in 
> order) and a common alternate (include n systems, starting with the
kth 
> one).  

That shouldn't be too difficult. It would mean, for instance, that you
could treat the first system differently to the others.

> Even though I've written 2000 page documents in LaTeX, I'd have 
> to think about how to do that for a bit.
> 
> I like the -H option as well -- it will greatly simplify invocation
for 
> this case, and cases like it.
> 
> On Nov 30, 2005, at 7:08 AM, Bernard Hurley wrote:
> 
> > I have thought of a better way of doing this:
> >
> > modify \lilypondfile so that it takes an optional argument as in:
> >
> > lilypondfile[reference]{mysong.ly}
> >
> > The idea is that without the optional parameter it would work as 
> > before,
> > but with the parameter, it would work as follows:
> >
> > 1] the eps files, (e.g. lily-1915112629-1.eps,
lily-1915112629-2.eps)
> > would be generated as before, but _not_ included in the tex file.
> >
> > 2] there would be tex commands automatically generated so that:
> >     \referenceBase would have value base name of generated files
> > (lily-1915112629 in this case)
> >     \referenceCount would have value number of eps files generated.
> > maybe we could also have:
> >     \referenceFile defined as the file name (mysong.ly in this case)
> >
> > This would mean that it would be easy to generate names of the .eps
> > files, any files containing headers (e.g. lily-1915112629.title)
etc,
> > these could then be input or dealt with in other ways. It opens up
all
> > sorts of possiblities. For instance if you wanted to put the
lilypond
> > source code into you document you could construct the name of it (in
> > this case lily-1915112629.ly). You would have complete control over
how
> > and where the files are processed. (So if you had a contents page
that
> > used a scaled down, and clipped version of the first system of a
son,
> > this could be done).
> >
> > I think I know how to do this, but there are a few minor bugs in
> > lilypondbook that need fixing first. I expect to be able to submit a
> > patch to the developer list in the next two weeks.
> >
> > It might also be a good idea if lilypond-book could take a -H option
> > that would then be passed on to lilypond.
> > -- 
> > Bernard Hurley <address@hidden>
> >
> 
-- 
Bernard Hurley <address@hidden>