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
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user