Re: Variable weirdness

[Timothy Lanfear]

On 17/12/16 17:04, David Sumbler wrote:
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.




I can't say I understand what is wrong with your attempt, but here is a 
version that does work and may help you to move forward. By using Scheme 
directly, you can see exactly how the bits are assembled.


\version "2.19.48"

printFluteA =
\new Staff \relative c'' {
  b1 | c \bar "|." |
}

printMvtOne =
\new StaffGroup <<
  \printFluteA
>>

printScoreMusic =
\bookpart {
  \score { \printMvtOne }
}

ScoreBook =
\book {
  \bookOutputName "foo"
}

#(begin
 (ly:book-add-bookpart! ScoreBook printScoreMusic)
 (ly:book-process ScoreBook $defaultpaper $defaultlayout 
(paper-variable ScoreBook 'output-filename)))



--
Timothy Lanfear, Bristol, UK.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[David Sumbler]

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

Re: Variable weirdness

[David Sumbler]

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 have 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
On Tue, 2016-11-08 at 07:44 +0100, Jan-Peter Voigt wrote:
> Hello,
> 
> here is a demo of the code:
> 
> %%% snip
> \version "2.19.49"
> 
> % the 2.18 version would just use parser and layout in the signature
> and 
> the additional parser-argument in the ly:parser-define! call
> parserDefine =
> #(define-scheme-function (vkey val)(symbol? scheme?)
> (ly:parser-define! vkey val))
> 
>  Demo
> 
> \parserDefine music \relative c'' { c b bes a }
> 
> { \music }
> %%% /snip
> 
> HTH
> Jan-Peter
> 
> Am 08.11.2016 um 07:06 schrieb Jan-Peter Voigt:
> > 
> > Hello,
> > 
> > in these situations I use a little scheme-function like this:
> > 
> > parserDefine =
> > #(define-scheme-function (key val)(symbol? scheme?)
> > (ly:parser-define! key val))
> > 
> > !!!(I will correct this later, when I am on real computer )
> > 
> > This scheme-function works on every level defining a variable into
> > the 
> > current parser.
> > 
> > HTH
> > Jan-Peter
> > 
> > Am 7. November 2016 23:55:00 MEZ, schrieb Simon Albrecht 
> > :
> > 
> > On 07.11.2016 17:56, David Kastrup wrote:
> > 
> > David Sumbler  writes:
> > 
> > I had the following lines in the main file of my
> > current
> > Lilypond project: \book { \bookOutputName
> > "../firstCello"
> > partName = "Cello 1" \include "frontcover.ily"
> > \bookpart {
> > %music... The file "frontcover.ily" contains a
> > \bookpart
> > block which prints a front cover with title, composer
> > etc.
> > - these are defined elsewhere. But it needs one more
> > variable, viz. 'partName'. I discovered that Lilypond
> > will
> > not accept a variable definition in Lilypond format in
> > the
> > position I have put it: at the top level of a \book
> > block.
> > Nor will it accept it in a \bookpart block. But at a
> > higher or a lower level, it will. This seems a bit
> > weird
> > (to say the least), in view of the fact that by
> > replacing
> > the line partName = "Cello 1" with the Scheme form
> > #(define partName "Cello 1") everything works as
> > intended.
> > Is there any useful reason why a variable cannot be
> > defined in Lilypond format in these contexts? 
> > 
> > Because they would not be local to these contexts? 
> > 
> > 
> > In other words, to make this work, books and bookparts would
> > need their
> > own namespaces, am I right? What would be the drawbacks of
> > that? I
> > daresay it would be pretty intuitive to use, and I’ve also
> > found myself
> > wanting that feature in the past, mainly to simplify \include
> > structures.
> > 
> > Best, Simon
> > 
> > ---
> > -
> > 
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> > 
> > -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9
> > Mail 
> > gesendet.
> > 
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> ___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[David Sumbler]

Thank you.  I might find this useful some time, if I have correctly
understood what the purpose of it is.

For the particular case I was concerned with, though, simply using
#(define partName "Cello 1")
seems a lot simpler.

I just wondered why the Lilypond form isn't allowed in a situation
where the Scheme form works absolutely fine.  I'm still wondering.

David


On Tue, 2016-11-08 at 07:44 +0100, Jan-Peter Voigt wrote:
> Hello,
> 
> here is a demo of the code:
> 
> %%% snip
> \version "2.19.49"
> 
> % the 2.18 version would just use parser and layout in the signature
> and 
> the additional parser-argument in the ly:parser-define! call
> parserDefine =
> #(define-scheme-function (vkey val)(symbol? scheme?)
> (ly:parser-define! vkey val))
> 
>  Demo
> 
> \parserDefine music \relative c'' { c b bes a }
> 
> { \music }
> %%% /snip
> 
> HTH
> Jan-Peter
> 
> Am 08.11.2016 um 07:06 schrieb Jan-Peter Voigt:
> > 
> > Hello,
> > 
> > in these situations I use a little scheme-function like this:
> > 
> > parserDefine =
> > #(define-scheme-function (key val)(symbol? scheme?)
> > (ly:parser-define! key val))
> > 
> > !!!(I will correct this later, when I am on real computer )
> > 
> > This scheme-function works on every level defining a variable into
> > the 
> > current parser.
> > 
> > HTH
> > Jan-Peter
> > 
> > Am 7. November 2016 23:55:00 MEZ, schrieb Simon Albrecht 
> > :
> > 
> > On 07.11.2016 17:56, David Kastrup wrote:
> > 
> > David Sumbler  writes:
> > 
> > I had the following lines in the main file of my
> > current
> > Lilypond project: \book { \bookOutputName
> > "../firstCello"
> > partName = "Cello 1" \include "frontcover.ily"
> > \bookpart {
> > %music... The file "frontcover.ily" contains a
> > \bookpart
> > block which prints a front cover with title, composer
> > etc.
> > - these are defined elsewhere. But it needs one more
> > variable, viz. 'partName'. I discovered that Lilypond
> > will
> > not accept a variable definition in Lilypond format in
> > the
> > position I have put it: at the top level of a \book
> > block.
> > Nor will it accept it in a \bookpart block. But at a
> > higher or a lower level, it will. This seems a bit
> > weird
> > (to say the least), in view of the fact that by
> > replacing
> > the line partName = "Cello 1" with the Scheme form
> > #(define partName "Cello 1") everything works as
> > intended.
> > Is there any useful reason why a variable cannot be
> > defined in Lilypond format in these contexts? 
> > 
> > Because they would not be local to these contexts? 
> > 
> > 
> > In other words, to make this work, books and bookparts would
> > need their
> > own namespaces, am I right? What would be the drawbacks of
> > that? I
> > daresay it would be pretty intuitive to use, and I’ve also
> > found myself
> > wanting that feature in the past, mainly to simplify \include
> > structures.
> > 
> > Best, Simon
> > 
> > ---
> > -
> > 
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> > 
> > -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9
> > Mail 
> > gesendet.
> > 
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > https://lists.gnu.org/mailman/listinfo/lilypond-user
> 

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[Jan-Peter Voigt]

Hello,

here is a demo of the code:

%%% snip
\version "2.19.49"

% the 2.18 version would just use parser and layout in the signature and 
the additional parser-argument in the ly:parser-define! call

parserDefine =
#(define-scheme-function (vkey val)(symbol? scheme?)
   (ly:parser-define! vkey val))

 Demo

\parserDefine music \relative c'' { c b bes a }

{ \music }
%%% /snip

HTH
Jan-Peter

Am 08.11.2016 um 07:06 schrieb Jan-Peter Voigt:

Hello,

in these situations I use a little scheme-function like this:

parserDefine =
#(define-scheme-function (key val)(symbol? scheme?)
(ly:parser-define! key val))

!!!(I will correct this later, when I am on real computer )

This scheme-function works on every level defining a variable into the 
current parser.


HTH
Jan-Peter

Am 7. November 2016 23:55:00 MEZ, schrieb Simon Albrecht 
:


On 07.11.2016 17:56, David Kastrup wrote:

David Sumbler  writes:

I had the following lines in the main file of my current
Lilypond project: \book { \bookOutputName "../firstCello"
partName = "Cello 1" \include "frontcover.ily" \bookpart {
%music... The file "frontcover.ily" contains a \bookpart
block which prints a front cover with title, composer etc.
- these are defined elsewhere. But it needs one more
variable, viz. 'partName'. I discovered that Lilypond will
not accept a variable definition in Lilypond format in the
position I have put it: at the top level of a \book block.
Nor will it accept it in a \bookpart block. But at a
higher or a lower level, it will. This seems a bit weird
(to say the least), in view of the fact that by replacing
the line partName = "Cello 1" with the Scheme form
#(define partName "Cello 1") everything works as intended.
Is there any useful reason why a variable cannot be
defined in Lilypond format in these contexts? 

Because they would not be local to these contexts? 



In other words, to make this work, books and bookparts would need their
own namespaces, am I right? What would be the drawbacks of that? I
daresay it would be pretty intuitive to use, and I’ve also found myself
wanting that feature in the past, mainly to simplify \include structures.

Best, Simon



lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail 
gesendet.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[Jan-Peter Voigt]

Hello,

in these situations I use a little scheme-function like this:

parserDefine =
#(define-scheme-function (key val)(symbol? scheme?)
  (ly:parser-define! key val))

!!!(I will correct this later, when I am on real computer )

This scheme-function works on every level defining a variable into the current 
parser.

HTH
Jan-Peter

Am 7. November 2016 23:55:00 MEZ, schrieb Simon Albrecht 
:
>On 07.11.2016 17:56, David Kastrup wrote:
>> David Sumbler  writes:
>>
>>> I had the following lines in the main file of my current Lilypond
>>> project:
>>>
>>> \book {
>>>\bookOutputName "../firstCello"
>>>  partName = "Cello 1"
>>>  \include "frontcover.ily"
>>>  \bookpart { %music...
>>>
>>> The file "frontcover.ily" contains a \bookpart block which prints a
>>> front cover with title, composer etc. - these are defined elsewhere.
>>>   But it needs one more variable, viz. 'partName'.
>>>
>>> I discovered that Lilypond will not accept a variable definition in
>>> Lilypond format in the position I have put it: at the top level of a
>>> \book block.  Nor will it accept it in a \bookpart block.  But at a
>>> higher or a lower level, it will.
>>>
>>> This seems a bit weird (to say the least), in view of the fact that
>by
>>> replacing the line
>>> partName = "Cello 1"
>>> with the Scheme form
>>> #(define partName "Cello 1")
>>> everything works as intended.
>>>
>>> Is there any useful reason why a variable cannot be defined in
>Lilypond
>>> format in these contexts?
>> Because they would not be local to these contexts?
>
>In other words, to make this work, books and bookparts would need their
>
>own namespaces, am I right? What would be the drawbacks of that? I 
>daresay it would be pretty intuitive to use, and I’ve also found myself
>
>wanting that feature in the past, mainly to simplify \include
>structures.
>
>Best, Simon
>
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[Simon Albrecht]

On 07.11.2016 17:56, David Kastrup wrote:

David Sumbler  writes:


I had the following lines in the main file of my current Lilypond
project:

\book {
   \bookOutputName "../firstCello"
 partName = "Cello 1"
 \include "frontcover.ily"
 \bookpart { %music...

The file "frontcover.ily" contains a \bookpart block which prints a
front cover with title, composer etc. - these are defined elsewhere.
  But it needs one more variable, viz. 'partName'.

I discovered that Lilypond will not accept a variable definition in
Lilypond format in the position I have put it: at the top level of a
\book block.  Nor will it accept it in a \bookpart block.  But at a
higher or a lower level, it will.

This seems a bit weird (to say the least), in view of the fact that by
replacing the line
partName = "Cello 1"
with the Scheme form
#(define partName "Cello 1")
everything works as intended.

Is there any useful reason why a variable cannot be defined in Lilypond
format in these contexts?

Because they would not be local to these contexts?


In other words, to make this work, books and bookparts would need their 
own namespaces, am I right? What would be the drawbacks of that? I 
daresay it would be pretty intuitive to use, and I’ve also found myself 
wanting that feature in the past, mainly to simplify \include structures.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[David Sumbler]

On Mon, 2016-11-07 at 17:56 +0100, David Kastrup wrote:
> David Sumbler  writes:
> 
> > 
> > I had the following lines in the main file of my current Lilypond
> > project:
> > 
> > \book {
> >   \bookOutputName "../firstCello"
> >     partName = "Cello 1"
> >     \include "frontcover.ily"
> > \bookpart { %music...
> > 
> > The file "frontcover.ily" contains a \bookpart block which prints a
> > front cover with title, composer etc. - these are defined
> > elsewhere.
> >  But it needs one more variable, viz. 'partName'.
> > 
> > I discovered that Lilypond will not accept a variable definition in
> > Lilypond format in the position I have put it: at the top level of
> > a
> > \book block.  Nor will it accept it in a \bookpart block.  But at a
> > higher or a lower level, it will.
> > 
> > This seems a bit weird (to say the least), in view of the fact that
> > by
> > replacing the line 
> > partName = "Cello 1"
> > with the Scheme form
> > #(define partName "Cello 1")
> > everything works as intended.
> > 
> > Is there any useful reason why a variable cannot be defined in
> > Lilypond
> > format in these contexts?
> Because they would not be local to these contexts?  Have you tried
> putting them into a \header block?

I had not tried a \header block, but I have now!

Putting a \header block inside the \book block or the \bookpart block
does mean that that assignment of the variable no longer produces an
error.  Unfortunately the variable is not recognized by the following
\markup section within the bookpart, and I get an "unknown escaped
string" error.

David

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable weirdness

[David Kastrup]

David Sumbler  writes:

> I had the following lines in the main file of my current Lilypond
> project:
>
> \book {
>   \bookOutputName "../firstCello"
>     partName = "Cello 1"
>     \include "frontcover.ily"
> \bookpart { %music...
>
> The file "frontcover.ily" contains a \bookpart block which prints a
> front cover with title, composer etc. - these are defined elsewhere.
>  But it needs one more variable, viz. 'partName'.
>
> I discovered that Lilypond will not accept a variable definition in
> Lilypond format in the position I have put it: at the top level of a
> \book block.  Nor will it accept it in a \bookpart block.  But at a
> higher or a lower level, it will.
>
> This seems a bit weird (to say the least), in view of the fact that by
> replacing the line 
>   partName = "Cello 1"
> with the Scheme form
>   #(define partName "Cello 1")
> everything works as intended.
>
> Is there any useful reason why a variable cannot be defined in Lilypond
> format in these contexts?

Because they would not be local to these contexts?  Have you tried
putting them into a \header block?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user