Further to my earllier message, I have realized that the problem I am getting has nothing to do with variable scope (at least, I don't think it does), so I was asking the wrong question. But the problem still exists. My abbreviated file now looks like this: %%%%% \version "2.19.48" \language "english" printFluteA = \new Staff \relative c'' { b1 | c \bar "|." | } printMvtOne = \new StaffGroup << \printFluteA >> printScoreMusic = \bookpart { \score { \printMvtOne } } \book { \bookOutputName "../ExperimentScore" \printScoreMusic } %%%%% As I mentioned before, the final line produces an " unexpected BOOK_IDENTIFIER" error, but not if the preceding \bookOutputName line is commented out. What is going on here? David On Sat, 2016-12-17 at 14:48 +0000, David Sumbler wrote: > I have again been trying to build up a sensible files-and-variables > structure for more complex scores (e.g. orchestral pieces with > several movements), and I seem once again to hav##SELECTION_END##e > run into the limitation that 'book' and 'bookpart' have no scope for > variables. > > So I thought I would try Jan-Peter's parserDefine function, but I am > still getting a problem. I cannot fathom whether I have used the > function incorrectly, or whether what I am trying to do is outside of > its functionality. > > I have pared my file down virtually to a minimum to demonstrate the > problem. This is what I now have: > > %%%%% > \version "2.19.48" > > \language "english" > > parserDefine = > #(define-scheme-function (vkey val)(symbol? scheme?) > (ly:parser-define! vkey val)) > > printFluteA = > \new Staff \relative c'' { > b1 | c \bar "|." | > } > > printMvtOne = > \new StaffGroup << > \printFluteA > >> > > \parserDefine printScoreMusic \bookpart { \score { \printMvtOne } } > > %printScore = > \book { > \bookOutputName "../ExperimentScore" > \printScoreMusic > } > %%%%% > > When I compile this, the \printScoreMusic line produces a syntax > error: unexpected BOOK_IDENTIFIER > > The funny thing is, that if I comment out the preceding > \bookOutputName line, there is no error and the file compiles as one > would expect. > > Can anyone shed light on this behaviour, and see a solution? > > David
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user