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

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
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. reference@base 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 <[hidden email]>
> >
>
--
Bernard Hurley <[hidden email]>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
On Thu, 2005-12-01 at 14:02 +0000, Bernard Hurley wrote:
> 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.
>
Sorry it wouldn't quite work like this. Perhaps something like
        \lilypondfile[options]{filename,reference}
would be better
--
Bernard Hurley <[hidden email]>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Michael Haynie
OK, I'm back from Alaska.  Sorry for the delay.

LaTeX macros with multiple parameters typically separate them with {},
so it would look like this:

\lilypondfile[options]{filename}{reference}

I thought we'd have lilypond-book provide the reference number, so I'm
not sure what the reference would be, but I suppose that it could be
provided by lilypond-book during the rewrite step.  The rewrite is
currently replacing the call with stuff surrounding an \input.  I think
I'd replace the \input with a call to yet another macro to be user
defined, maybe following the \ifx pattern used by pre and post
LilyPondExample.  Something like:

\includeLilypondSystems{reference number}{system count}

The user would define includeLilypondSystems to e.g. discard the title,
print the first system, or whatever.  The main weakness that I see is
that users would have to redefine the macro if they need to use several
definitions in the same book.  I'm not sure I know why one would want
to do that, but my need to do my own titles suggests that others might
need to do similarly odd things.

On Dec 2, 2005, at 8:53 AM, Bernard Hurley wrote:

> On Thu, 2005-12-01 at 14:02 +0000, Bernard Hurley wrote:
>> 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.
>>
> Sorry it wouldn't quite work like this. Perhaps something like
> \lilypondfile[options]{filename,reference}
> would be better
> --
> Bernard Hurley <[hidden email]>
>



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
Hi,

I was going to post this stuff on Sunday, however I live in Hemel
Hempstead and have been a bit pre-occupied with other things. Here is a
first attempt at solving the problem.  I might not have much time to
work on this in the near future, but would appreciate any suggestions.

I attach a file called "lilypond-macros" (not a very good name -maybe
someone can think of another one). You will have to do a bit of editing
to get it working on your system (I think I have documented it enough in
the file - if you search for "invisible" you should find the lines that
need changing).

If you compare the effect of running:

        lilypond-book -V --psfonts <name>.lytex

and:

        lilypond-macros -V --psfonts <name>.lytex

You will see that l-b substitutes inline code for the embedded LaTeX
code whereas l-m substitutes a call to "\lilyInputSystems". This macro
is contained in a file "<name>.mac" that is "\input" at the top of the
resulting .tex file.

>From now on "<name>.mac" can be used in _any_ TeX file. You must write:

        \usepackage{graphics}  %% or: \usepackage{graphicx}
        \include <name>.mac

in your preamble. The macros available are:

1] \lilyInputSystems{<song name>}

        This macro causes the music to be displayed so that it looks identical
the corresponding inline code generated by l-b. It takes account of
parameters "quote" and "verbatim" if they have been used in the
original .lytex file. The macros below do _not_ do this.

2] \lilyInputSingle{<song name>}{<system number>}

         A single system is displayed.

3] \lilyInputRange{<song name>}{<first system>}{<last system>}

        a Range of systems is displayed

4] \lilyInputVerbatim{<song name>}

        the verbatim lilypond code is displayed

5] \lilyHeader{<song name>}{<header name>}

        The lilypond header named "<header name>" is displayed.
At present l-m only finds the _first_ header block in the code. Also the
macro is fragile so you should write:

        \section{\protect\lilyHeader{.......

not:

        \section{\lilyHeader{......


Some points:

A] The song names are at present generated by l-m etc. and have the form
"SongA", "SongB" etc... And you will have to look in the generated .tex
code to see what they are.

B] The systems are numbered starting from "1". You will obviously have
to turn the generated .tex into .ps or .pdf to find out how many there
are!

C] If you are happy with the generated macros you don't actually have to
run l-m again. You can simply work with .tex

D] At present you cannot "\import" two .mac files into the same LaTeX
file. Eventually it should be possible to gnerate libraries of songs for
use in LaTeX.

e] You don't need all the generated files to use the macros. The ones
you need in addition to the .mac file are:

        lilyXXXXXXXXXX-n.eps
        lilyXXXXXXXXXX-verb.tex
        lilyXXXXXXXXXX-verb1.tex

And if you are using the --psfonts option, <name>.psfonts will be needed
by dvips.
       

        /Bernard


On Sat, 2005-12-10 at 21:37 -0500, Michael Haynie wrote:

> OK, I'm back from Alaska.  Sorry for the delay.
>
> LaTeX macros with multiple parameters typically separate them with {},
> so it would look like this:
>
> \lilypondfile[options]{filename}{reference}
>
> I thought we'd have lilypond-book provide the reference number, so I'm
> not sure what the reference would be, but I suppose that it could be
> provided by lilypond-book during the rewrite step.  The rewrite is
> currently replacing the call with stuff surrounding an \input.  I think
> I'd replace the \input with a call to yet another macro to be user
> defined, maybe following the \ifx pattern used by pre and post
> LilyPondExample.  Something like:
>
> \includeLilypondSystems{reference number}{system count}
>
> The user would define includeLilypondSystems to e.g. discard the title,
> print the first system, or whatever.  The main weakness that I see is
> that users would have to redefine the macro if they need to use several
> definitions in the same book.  I'm not sure I know why one would want
> to do that, but my need to do my own titles suggests that others might
> need to do similarly odd things.
>
> On Dec 2, 2005, at 8:53 AM, Bernard Hurley wrote:
>
> > On Thu, 2005-12-01 at 14:02 +0000, Bernard Hurley wrote:
> >> 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.
> >>
> > Sorry it wouldn't quite work like this. Perhaps something like
> > \lilypondfile[options]{filename,reference}
> > would be better
> > --
> > Bernard Hurley <[hidden email]>
> >
>
--
Bernard Hurley <[hidden email]>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
Sorry, forgot the attachment!

        /Bernard

On Tue, 2005-12-13 at 08:55 +0000, Bernard Hurley wrote:

> Hi,
>
> I was going to post this stuff on Sunday, however I live in Hemel
> Hempstead and have been a bit pre-occupied with other things. Here is a
> first attempt at solving the problem.  I might not have much time to
> work on this in the near future, but would appreciate any suggestions.
>
> I attach a file called "lilypond-macros" (not a very good name -maybe
> someone can think of another one). You will have to do a bit of editing
> to get it working on your system (I think I have documented it enough in
> the file - if you search for "invisible" you should find the lines that
> need changing).
>
> If you compare the effect of running:
>
> lilypond-book -V --psfonts <name>.lytex
>
> and:
>
> lilypond-macros -V --psfonts <name>.lytex
>
> You will see that l-b substitutes inline code for the embedded LaTeX
> code whereas l-m substitutes a call to "\lilyInputSystems". This macro
> is contained in a file "<name>.mac" that is "\input" at the top of the
> resulting .tex file.
>
> >From now on "<name>.mac" can be used in _any_ TeX file. You must write:
>
> \usepackage{graphics}  %% or: \usepackage{graphicx}
> \include <name>.mac
>
> in your preamble. The macros available are:
>
> 1] \lilyInputSystems{<song name>}
>
> This macro causes the music to be displayed so that it looks identical
> the corresponding inline code generated by l-b. It takes account of
> parameters "quote" and "verbatim" if they have been used in the
> original .lytex file. The macros below do _not_ do this.
>
> 2] \lilyInputSingle{<song name>}{<system number>}
>
> A single system is displayed.
>
> 3] \lilyInputRange{<song name>}{<first system>}{<last system>}
>
> a Range of systems is displayed
>
> 4] \lilyInputVerbatim{<song name>}
>
> the verbatim lilypond code is displayed
>
> 5] \lilyHeader{<song name>}{<header name>}
>
> The lilypond header named "<header name>" is displayed.
> At present l-m only finds the _first_ header block in the code. Also the
> macro is fragile so you should write:
>
> \section{\protect\lilyHeader{.......
>
> not:
>
> \section{\lilyHeader{......
>
>
> Some points:
>
> A] The song names are at present generated by l-m etc. and have the form
> "SongA", "SongB" etc... And you will have to look in the generated .tex
> code to see what they are.
>
> B] The systems are numbered starting from "1". You will obviously have
> to turn the generated .tex into .ps or .pdf to find out how many there
> are!
>
> C] If you are happy with the generated macros you don't actually have to
> run l-m again. You can simply work with .tex
>
> D] At present you cannot "\import" two .mac files into the same LaTeX
> file. Eventually it should be possible to gnerate libraries of songs for
> use in LaTeX.
>
> e] You don't need all the generated files to use the macros. The ones
> you need in addition to the .mac file are:
>
> lilyXXXXXXXXXX-n.eps
> lilyXXXXXXXXXX-verb.tex
> lilyXXXXXXXXXX-verb1.tex
>
> And if you are using the --psfonts option, <name>.psfonts will be needed
> by dvips.
>
>
> /Bernard
>
>
> On Sat, 2005-12-10 at 21:37 -0500, Michael Haynie wrote:
> > OK, I'm back from Alaska.  Sorry for the delay.
> >
> > LaTeX macros with multiple parameters typically separate them with {},
> > so it would look like this:
> >
> > \lilypondfile[options]{filename}{reference}
> >
> > I thought we'd have lilypond-book provide the reference number, so I'm
> > not sure what the reference would be, but I suppose that it could be
> > provided by lilypond-book during the rewrite step.  The rewrite is
> > currently replacing the call with stuff surrounding an \input.  I think
> > I'd replace the \input with a call to yet another macro to be user
> > defined, maybe following the \ifx pattern used by pre and post
> > LilyPondExample.  Something like:
> >
> > \includeLilypondSystems{reference number}{system count}
> >
> > The user would define includeLilypondSystems to e.g. discard the title,
> > print the first system, or whatever.  The main weakness that I see is
> > that users would have to redefine the macro if they need to use several
> > definitions in the same book.  I'm not sure I know why one would want
> > to do that, but my need to do my own titles suggests that others might
> > need to do similarly odd things.
> >
> > On Dec 2, 2005, at 8:53 AM, Bernard Hurley wrote:
> >
> > > On Thu, 2005-12-01 at 14:02 +0000, Bernard Hurley wrote:
> > >> 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.
> > >>
> > > Sorry it wouldn't quite work like this. Perhaps something like
> > > \lilypondfile[options]{filename,reference}
> > > would be better
> > > --
> > > Bernard Hurley <[hidden email]>
> > >
> >
--
Bernard Hurley <[hidden email]>

lilypond-macros (55K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Spam:SpamScore 16.1] Re: extending \lilypondfile was: Re: Extracting header fields for use by e.g. LaTeX?

Michael Haynie
Glad to hear you were only _distracted_ by the events at Hemel  
Hempstead.

Thanks for the script.

I've been trying to test it, but I'm stuck.  The problem may be the  
result of a change between 2.6.x and 2.7.x or bad configuration on my  
part.  The script complains about an undefined variable,  
print-score-with-defaults.  That word is mentioned in the generated  
lilyK*.ly file, but I can't find a definition, though.  Any ideas?


The execution trace follows:

% lilypond-macros -f latex -V --psfonts working.ltx
datadir is /home/invisible/share/lilypond/2.7.23
lilypond_binary is lilypond
lilypond-macros (GNU LilyPond) 2.7.21
Reading working.ltx...
Invoking `latex tmpVa0Kzy.tex'This is pdfeTeX, Version  
3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./tmpVa0Kzy.tex
LaTeX2e <2003/12/01>
Babel <v3.8d> and hyphenation patterns for american, french, german,  
ngerman, b
ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,  
esperanto, e
stonian, finnish, greek, icelandic, irish, italian, latin, magyar,  
norsk, polis
h, portuges, romanian, russian, serbian, slovak, slovene, spanish,  
swedish, tur
kish, ukrainian, nohyphenation, loaded.

(/sw/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
(/sw/share/texmf-dist/tex/latex/base/size12.clo))
(/sw/share/texmf-dist/tex/latex/graphics/graphics.sty
(/sw/share/texmf-dist/tex/latex/graphics/trig.sty)
(/sw/share/texmf-dist/tex/latex/graphics/graphics.cfg)
(/sw/share/texmf-dist/tex/latex/graphics/dvips.def))
No file tmpVa0Kzy.aux.
textwidth=390.0pt
columnsep=10.0pt
(./tmpVa0Kzy.aux) )
No pages of output.
Transcript written on tmpVa0Kzy.log.

Dissecting...
Writing snippets...
lilyKAGHGDCBAII-verb1.tex is up to date.
lilyKBBGEFADHC-verb1.tex is up to date.
lilyKABBAFJDFFI-verb1.tex is up to date.
lilyKAIGDDBADDD-verb1.tex is up to date.

Processing...
Invoking `lilypond --formats=ps --backend eps  -I  
'/Users/mbh/SheetMusic/booktest' snippet-map.ly lilyKAGHGDCBAII  
lilyKBBGEFADHC lilyKABBAFJDFFI lilyKAIGDDBADDD'GNU LilyPond 2.6.4
Processing `snippet-map.ly'
Parsing...
Processing `working.ltx:11 (lilyKAGHGDCBAII.ly)'
Parsing...lilyKAGHGDCBAII.ly:1:1: In expression (set!  
toplevel-score-handler print-score-with-defaults):
lilyKAGHGDCBAII.ly:1:1: Unbound variable: print-score-with-defaults
lilypond-macros: warning: `lilypond' failed (status 2) (ignored)

lilypond-macros: error: Process lilypond --formats=ps --backend eps  -I  
  '/Users/mbh/SheetMusic/booktest' snippet-map.ly lilyKAGHGDCBAII  
lilyKBBGEFADHC lilyKABBAFJDFFI lilyKAIGDDBADDD exited unsuccessfully.
Removing `working.tex'
Traceback (most recent call last):
   File  
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros",  
line 1670, in ?
     main ()
   File  
"/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros",  
line 1653, in main
     ly.exit (1)
   File  
"/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/
python/lilylib.py", line 139, in exit
     raise _ ('Exiting (%d)...') % i
Exiting (1)...


On Dec 13, 2005, at 5:15 AM, Bernard Hurley wrote:

> Sorry, forgot the attachment!
>
> /Bernard
>
> On Tue, 2005-12-13 at 08:55 +0000, Bernard Hurley wrote:
>> Hi,
>>
>> I was going to post this stuff on Sunday, however I live in Hemel
>> Hempstead and have been a bit pre-occupied with other things. Here is  
>> a
>> first attempt at solving the problem.  I might not have much time to
>> work on this in the near future, but would appreciate any suggestions.
>>
>> I attach a file called "lilypond-macros" (not a very good name -maybe
>> someone can think of another one). You will have to do a bit of  
>> editing
>> to get it working on your system (I think I have documented it enough  
>> in
>> the file - if you search for "invisible" you should find the lines  
>> that
>> need changing).
>>
>> If you compare the effect of running:
>>
>> lilypond-book -V --psfonts <name>.lytex
>>
>> and:
>>
>> lilypond-macros -V --psfonts <name>.lytex
>>
>> You will see that l-b substitutes inline code for the embedded LaTeX
>> code whereas l-m substitutes a call to "\lilyInputSystems". This macro
>> is contained in a file "<name>.mac" that is "\input" at the top of the
>> resulting .tex file.
>>
>>> From now on "<name>.mac" can be used in _any_ TeX file. You must  
>>> write:
>>
>> \usepackage{graphics}  %% or: \usepackage{graphicx}
>> \include <name>.mac
>>
>> in your preamble. The macros available are:
>>
>> 1] \lilyInputSystems{<song name>}
>>
>> This macro causes the music to be displayed so that it looks  
>> identical
>> the corresponding inline code generated by l-b. It takes account of
>> parameters "quote" and "verbatim" if they have been used in the
>> original .lytex file. The macros below do _not_ do this.
>>
>> 2] \lilyInputSingle{<song name>}{<system number>}
>>
>> A single system is displayed.
>>
>> 3] \lilyInputRange{<song name>}{<first system>}{<last system>}
>>
>> a Range of systems is displayed
>>
>> 4] \lilyInputVerbatim{<song name>}
>>
>> the verbatim lilypond code is displayed
>>
>> 5] \lilyHeader{<song name>}{<header name>}
>>
>> The lilypond header named "<header name>" is displayed.
>> At present l-m only finds the _first_ header block in the code. Also  
>> the
>> macro is fragile so you should write:
>>
>> \section{\protect\lilyHeader{.......
>>
>> not:
>>
>> \section{\lilyHeader{......
>>
>>
>> Some points:
>>
>> A] The song names are at present generated by l-m etc. and have the  
>> form
>> "SongA", "SongB" etc... And you will have to look in the generated  
>> .tex
>> code to see what they are.
>>
>> B] The systems are numbered starting from "1". You will obviously have
>> to turn the generated .tex into .ps or .pdf to find out how many there
>> are!
>>
>> C] If you are happy with the generated macros you don't actually have  
>> to
>> run l-m again. You can simply work with .tex
>>
>> D] At present you cannot "\import" two .mac files into the same LaTeX
>> file. Eventually it should be possible to gnerate libraries of songs  
>> for
>> use in LaTeX.
>>
>> e] You don't need all the generated files to use the macros. The ones
>> you need in addition to the .mac file are:
>>
>> lilyXXXXXXXXXX-n.eps
>> lilyXXXXXXXXXX-verb.tex
>> lilyXXXXXXXXXX-verb1.tex
>>
>> And if you are using the --psfonts option, <name>.psfonts will be  
>> needed
>> by dvips.
>>
>>
>> /Bernard
>>
>>
>> On Sat, 2005-12-10 at 21:37 -0500, Michael Haynie wrote:
>>> OK, I'm back from Alaska.  Sorry for the delay.
>>>
>>> LaTeX macros with multiple parameters typically separate them with  
>>> {},
>>> so it would look like this:
>>>
>>> \lilypondfile[options]{filename}{reference}
>>>
>>> I thought we'd have lilypond-book provide the reference number, so  
>>> I'm
>>> not sure what the reference would be, but I suppose that it could be
>>> provided by lilypond-book during the rewrite step.  The rewrite is
>>> currently replacing the call with stuff surrounding an \input.  I  
>>> think
>>> I'd replace the \input with a call to yet another macro to be user
>>> defined, maybe following the \ifx pattern used by pre and post
>>> LilyPondExample.  Something like:
>>>
>>> \includeLilypondSystems{reference number}{system count}
>>>
>>> The user would define includeLilypondSystems to e.g. discard the  
>>> title,
>>> print the first system, or whatever.  The main weakness that I see is
>>> that users would have to redefine the macro if they need to use  
>>> several
>>> definitions in the same book.  I'm not sure I know why one would want
>>> to do that, but my need to do my own titles suggests that others  
>>> might
>>> need to do similarly odd things.
>>>
>>> On Dec 2, 2005, at 8:53 AM, Bernard Hurley wrote:
>>>
>>>> On Thu, 2005-12-01 at 14:02 +0000, Bernard Hurley wrote:
>>>>> 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.
>>>>>
>>>> Sorry it wouldn't quite work like this. Perhaps something like
>>>> \lilypondfile[options]{filename,reference}
>>>> would be better
>>>> --
>>>> Bernard Hurley <[hidden email]>
>>>>
>>>
> --
> Bernard Hurley <[hidden email]>
> <lilypond-macros>



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
On Tue, 2005-12-13 at 23:32 -0500, Michael Haynie wrote:

> Glad to hear you were only _distracted_ by the events at Hemel  
> Hempstead.
>
> Thanks for the script.
>
> I've been trying to test it, but I'm stuck.  The problem may be the  
> result of a change between 2.6.x and 2.7.x or bad configuration on my  
> part.  The script complains about an undefined variable,  
> print-score-with-defaults.  That word is mentioned in the generated  
> lilyK*.ly file, but I can't find a definition, though.  Any ideas?
>

It looks like some scheme names have changed change between versions
2.6.x and 2.7.x. Lines 554-558 of l-m read:

        #(set! toplevel-score-handler print-score-with-defaults)
        #(set! toplevel-music-handler (lambda (p m)
                                (print-score-with-defaults
                                 p (scorify-music m p))))

I copied these straight from l-b the 2.7.x version of l-b. The 2.6.x
version has:

        #(set! toplevel-score-handler ly:parser-print-score)
        #(set! toplevel-music-handler (lambda (p m)
                                (ly:parser-print-score
                                 p (ly:music-scorify m p))))

Try replacing the lines with the old version. A word of warning if you
don't know Python: the lines are _inside_ a Python multi-line string
which is then written into a .ly file. So if you want to comment out the
2.7.x code you have to use lilypond comments _not_ Python comments. Also
be aware that to get a "%" - the lilypond comment symbol yo have to type
"%%"

good luck

        /Bernard

> The execution trace follows:
>
> % lilypond-macros -f latex -V --psfonts working.ltx
> datadir is /home/invisible/share/lilypond/2.7.23
> lilypond_binary is lilypond
> lilypond-macros (GNU LilyPond) 2.7.21
> Reading working.ltx...
> Invoking `latex tmpVa0Kzy.tex'This is pdfeTeX, Version  
> 3.141592-1.21a-2.2 (Web2C 7.5.4)
> entering extended mode
> (./tmpVa0Kzy.tex
> LaTeX2e <2003/12/01>
> Babel <v3.8d> and hyphenation patterns for american, french, german,  
> ngerman, b
> ahasa, basque, bulgarian, catalan, croatian, czech, danish, dutch,  
> esperanto, e
> stonian, finnish, greek, icelandic, irish, italian, latin, magyar,  
> norsk, polis
> h, portuges, romanian, russian, serbian, slovak, slovene, spanish,  
> swedish, tur
> kish, ukrainian, nohyphenation, loaded.
>
> (/sw/share/texmf-dist/tex/latex/base/article.cls
> Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
> (/sw/share/texmf-dist/tex/latex/base/size12.clo))
> (/sw/share/texmf-dist/tex/latex/graphics/graphics.sty
> (/sw/share/texmf-dist/tex/latex/graphics/trig.sty)
> (/sw/share/texmf-dist/tex/latex/graphics/graphics.cfg)
> (/sw/share/texmf-dist/tex/latex/graphics/dvips.def))
> No file tmpVa0Kzy.aux.
> textwidth=390.0pt
> columnsep=10.0pt
> (./tmpVa0Kzy.aux) )
> No pages of output.
> Transcript written on tmpVa0Kzy.log.
>
> Dissecting...
> Writing snippets...
> lilyKAGHGDCBAII-verb1.tex is up to date.
> lilyKBBGEFADHC-verb1.tex is up to date.
> lilyKABBAFJDFFI-verb1.tex is up to date.
> lilyKAIGDDBADDD-verb1.tex is up to date.
>
> Processing...
> Invoking `lilypond --formats=ps --backend eps  -I  
> '/Users/mbh/SheetMusic/booktest' snippet-map.ly lilyKAGHGDCBAII  
> lilyKBBGEFADHC lilyKABBAFJDFFI lilyKAIGDDBADDD'GNU LilyPond 2.6.4
> Processing `snippet-map.ly'
> Parsing...
> Processing `working.ltx:11 (lilyKAGHGDCBAII.ly)'
> Parsing...lilyKAGHGDCBAII.ly:1:1: In expression (set!  
> toplevel-score-handler print-score-with-defaults):
> lilyKAGHGDCBAII.ly:1:1: Unbound variable: print-score-with-defaults
> lilypond-macros: warning: `lilypond' failed (status 2) (ignored)
>
> lilypond-macros: error: Process lilypond --formats=ps --backend eps  -I  
>   '/Users/mbh/SheetMusic/booktest' snippet-map.ly lilyKAGHGDCBAII  
> lilyKBBGEFADHC lilyKABBAFJDFFI lilyKAIGDDBADDD exited unsuccessfully.
> Removing `working.tex'
> Traceback (most recent call last):
>    File  
> "/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros",  
> line 1670, in ?
>      main ()
>    File  
> "/Applications/LilyPond.app//Contents/Resources/bin/lilypond-macros",  
> line 1653, in main
>      ly.exit (1)
>    File  
> "/Applications/LilyPond.app/Contents/Resources/share/lilypond/current/
> python/lilylib.py", line 139, in exit
>      raise _ ('Exiting (%d)...') % i
> Exiting (1)...
>
>  <lilypond-macros>
>
--
Bernard Hurley <[hidden email]>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Michael Haynie
In reply to this post by Bernard Hurley-3

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:

* lilypondSystemMacros.tex contains implementations of some useful TeX
macros.  They can be used without modification -- they only need to be
included in the document at some point -- preferably in the preamble.  
It will be best to provide this file in the distribution to be
included, as opposed to generated in the source directory each time.  
There is a fair amount of commentary on what the various parts are
doing.  I didn't include every facility in the original, since I wasn't
completely certain what it's all for.  I'm probably missing something
-- maybe a verbatim facility?  Error handling isn't especially complete
either.  We can refine that later.  There may be some stupid programmer
tricks in the LaTeX macros -- stay alert.

* example.tex contains an example of use, including several
alternatives.  It is the generated file instead of the source file, but
you get the idea.

The generated code should look like this:

The author writes this:
        \lilypondfile[staffsize=24]{BattleBelongsToTheLordBook.ly}
which becomes this:
        \lilyInputExample{2098660014}{8}

Lilypondbook would continue to produce eps files like
lily-2098660014-1.eps, etc, as it does now.

I also think there should be a -H all argument to extract all defined
header fields.

I'm satisfied that these macros and transformations will allow the
construction of a song book without any editing of intermediate files.

I'd hack the lilypondmacro program, but I have not yet learned python,
and wanted to share the above thoughts first.


 


Thoughts?

_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel

lilypondSystemMacros.tex (7K) Download Attachment
example.tex (965 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Haynie
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
>
>

_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel

lilypondSystemMacros.tex (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
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.
>

If you have a look at my new veraion of "lilypond-macros" you will see
it extracts all headers from the .ly files.  It does this by examining
the .ly file directly. The headers don't have to be the usual lilypond
ones.

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

This could be done in lilypond-macros itself. At present it merely puts
in backslashes to stop LaTeX choking.


> 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 <[hidden email]>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
In reply to this post by Michael Haynie
On Sun, 2006-01-01 at 13:12 -0500, Michael Haynie wrote:

Some more thoughts on markup:

1] My method of dealing with this does not currently handle lilypond
markup at all. This is because it uses regular expressions to handle the
header block and assumes the first "}" is the end of the block. It would
be possible to patch this up a bit using regular expressions - for
instance ignoring "}" symbols that occur in quotes. But this would
assume all the header fields look like:

        field = "value"

(There is still the problem of quotes in quotes, but there are ways
round this.) To do anything more sophisticated would require a parser.

2] If you are going to use a lilypond-book-like program to handle the
formatting, why bother about lilypond markup at all? Why not simply
allow LaTeX markup within the "value" string? A clean way of doing this
would be to have extra headers like "latextitle" etc. The idea being
that if only "title" exits we use it, but if "latextitle" exists we
substitute that.

3] There is still the problem of actually extracting a header containing
lilypond markup, which, as I say, my code dosn't do yet, All header
entries seem to have one of the formats:

        field = "value"
        field = ##t
        field = ##f
        field = #( ... scheme code ... )
        field = \markup .... text markup .....

If [2] is implemented then we are not going to translate this into LaTeX
and so a fairly simple parser could be used, one that merely recognises
the correct format for markup etc. It could a string in all cases, or
may be simply ignore entries not of the first type. In any case it would
be easier than trying to do the translation into LaTeX markup, and would
be less afected by changes in the lilypond parser.

        /Bernard

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



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Han-Wen Nienhuys
In reply to this post by Bernard Hurley-3
Bernard Hurley wrote:

>>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.
>>
>
>
> If you have a look at my new veraion of "lilypond-macros" you will see
> it extracts all headers from the .ly files.  It does this by examining
> the .ly file directly. The headers don't have to be the usual lilypond
> ones.

Our advice is usually to let Lily do the work of looking at .ly files.
It should be relatively easy to make it extract all of the headers. See

(define-public (output-scopes scopes fields basename)

in backend-library.scm

--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Bernard Hurley-3
On Thu, 2006-01-05 at 14:40 +0100, Han-Wen Nienhuys wrote:

> >
> > If you have a look at my new veraion of "lilypond-macros" you will see
> > it extracts all headers from the .ly files.  It does this by examining
> > the .ly file directly. The headers don't have to be the usual lilypond
> > ones.
>
> Our advice is usually to let Lily do the work of looking at .ly files.
> It should be relatively easy to make it extract all of the headers. See
>
> (define-public (output-scopes scopes fields basename)
>
> in backend-library.scm
>

Actually that is what I was thinking of doing eventually. My usual
approach is first to do something that I "know" will work and then to
re-factor it into something more sensible. What I actually want to do is
extract the headers as a list of <header,value> pairs without having to
know, in advance, what headers exist.

--
Bernard Hurley <[hidden email]>


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

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

Michael Haynie
In reply to this post by 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 <[hidden email]>
> <lilypond-macros>



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel