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

14 messages
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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 .lytex and:         lilypond-macros -V --psfonts .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 ".mac" that is "\input" at the top of the resulting .tex file. >From now on ".mac" can be used in _any_ TeX file. You must write:         \usepackage{graphics}  %% or: \usepackage{graphicx}         \include .mac in your preamble. The macros available are: 1] \lilyInputSystems{}         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{}{}          A single system is displayed. 3] \lilyInputRange{}{}{}         a Range of systems is displayed 4] \lilyInputVerbatim{}         the verbatim lilypond code is displayed 5] \lilyHeader{}{
}         The lilypond header named "
" 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, .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
Open this post in threaded view
|

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

 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 .lytex > > and: > > lilypond-macros -V --psfonts .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 ".mac" that is "\input" at the top of the > resulting .tex file. > > >From now on ".mac" can be used in _any_ TeX file. You must write: > > \usepackage{graphics}  %% or: \usepackage{graphicx} > \include .mac > > in your preamble. The macros available are: > > 1] \lilyInputSystems{} > > 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{}{} > > A single system is displayed. > > 3] \lilyInputRange{}{}{} > > a Range of systems is displayed > > 4] \lilyInputVerbatim{} > > the verbatim lilypond code is displayed > > 5] \lilyHeader{}{
} > > The lilypond header named "
" 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, .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
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?

 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 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 .lytex >> >> and: >> >> lilypond-macros -V --psfonts .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 ".mac" that is "\input" at the top of the >> resulting .tex file. >> >>> From now on ".mac" can be used in _any_ TeX file. You must   >>> write: >> >> \usepackage{graphics}  %% or: \usepackage{graphicx} >> \include .mac >> >> in your preamble. The macros available are: >> >> 1] \lilyInputSystems{} >> >> 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{}{} >> >> A single system is displayed. >> >> 3] \lilyInputRange{}{}{} >> >> a Range of systems is displayed >> >> 4] \lilyInputVerbatim{} >> >> the verbatim lilypond code is displayed >> >> 5] \lilyHeader{}{
} >> >> The lilypond header named "
" 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, .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
Open this post in threaded view
|

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

 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 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)... > >   > -- Bernard Hurley <[hidden email]> _______________________________________________ lilypond-devel mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/lilypond-devel
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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
Open this post in threaded view
|

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

 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