Variables when compiling a book

2015-02-02 Thread John McWilliam
I am compiling a collection of bagpipe tunes and am having a problem when the
individual files are to be compiled into a book. Many of the tunes have
sections of music defined in variables - these definitions lie outside the
\score context and are causing errors when I try to compile the book.

I have also noticed that my list of \include files also defined outside the
score context have to be  removed form the individual tunes and listed at
the beginning of the book file instead. This is not a problem since the list
is short, however, moving all my music variables to the book file seems like
a clumsy way of doing things since they are many and vary from tune to tune. 

Does anyone have a solution to this problem which could perhaps be described
as one of SCOPE or CONTEXT?



-
John McWilliam
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Variables-when-compiling-a-book-tp171346.html
Sent from the User mailing list archive at Nabble.com.

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


Re: Variables when compiling a book

2015-02-02 Thread Hans Aberg

> On 2 Feb 2015, at 21:34, John McWilliam  wrote:
> 
> I am compiling a collection of bagpipe tunes and am having a problem when the
> individual files are to be compiled into a book. Many of the tunes have
> sections of music defined in variables - these definitions lie outside the
> \score context and are causing errors when I try to compile the book.

Have you tried LilyPond-Book, which admits collecting separate .ly files into a 
book?



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


Re: Variables when compiling a book

2015-02-02 Thread Christopher R. Maden
On 02/02/2015 02:34 PM, John McWilliam wrote:
> I am compiling a collection of bagpipe tunes and am having a problem
> when the individual files are to be compiled into a book. Many of the
> tunes have sections of music defined in variables - these definitions
> lie outside the \score context and are causing errors when I try to
> compile the book.
> 
> I have also noticed that my list of \include files also defined
> outside the score context have to be  removed form the individual
> tunes and listed at the beginning of the book file instead. This is
> not a problem since the list is short, however, moving all my music
> variables to the book file seems like a clumsy way of doing things
> since they are many and vary from tune to tune.
> 
> Does anyone have a solution to this problem which could perhaps be
> described as one of SCOPE or CONTEXT?

Unfortunately, this is one of the cases where LilyPond use resembles
other kinds of computer programming.  You’ll need to refactor your files...

I’ve made a few books of songs or tunes.  The music for each tune (or
song) goes in its own file; there is a sibling wrapper for each tune
that produces discrete output, which \includes the core music file.
Then the book file \includes the music for all the tunes.

A short example:

=-=-=-= atholl_highlanders_tune.ly =-=-=-=

\version "2.16.2"

athollLayout = { ... }
athollFullChords = { ... }
athollFullTune = { ... }

=-=-=-= end =-=-=-=

=-=-=-= atholl_highlanders.ly =-=-=-=

\version "2.16.2"
\include "atholl_highlanders_tune.ly"
theFullChords = \athollFullChords
theFullTune = \athollFullTune
theLayout = \athollLayout
theTempo = #(ly:make-moment 420 8)
theTitle = "The Atholl Highlanders"
% tunes.ly actually handles the layout and MIDI
% generation, given these variables
\include "tunes.ly"

=-=-=-= end =-=-=-=

=-=-=-= crism_tunes.ly =-=-=-=

\version "2.16.2"
\include "atholl_highlanders_tune.ly"
% ...
\book {
  % ...
  \bookpart {
\header {
  title = "Jigs"
}
\score {
  \athollLayout
  \header {
title = "The Atholl Highlanders"
}
  }
  \layout {}
}
% ...
  }
  % ...
}

=-=-=-= end =-=-=-=

Now, I end up actually generating the wrapper files and the book .ly
from an XML file, so that I can easily handle redundant information
(indexes by alternate titles and key, e.g.), but that’s for a different
time.

To see the full files for a single tune, see http://music.maden.org/index.php?title=The_Atholl_Highlanders >; for a
tune book sample, see http://crism.maden.org/music/crism_tunes.xml
>, http://crism.maden.org/music/crism_tunes.ly >, and http://crism.maden.org/music/crism_tunes.pdf >.

~Chris
-- 
Chris Maden, text nerd  http://crism.maden.org/ >
Surround hate and force it to surrender.
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9  A210 4A51 DBAC 5C5C 3D5E

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


Re: Variables when compiling a book

2015-02-03 Thread John McWilliam
>Unfortunately, this is one of the cases where LilyPond use resembles
>other kinds of computer programming.  You’ll need to refactor your files...

This solution presented a completely new mind set for me. The problem is
that I already have a considerable collection of bagpipe tunes written
without user-defined variables and compiled into books of marches and dance
tunes (see: https://github.com/jsmcwilliam/My_Bagpipemusic). On examination
of any tune you will see the construct fairly easily. These are then
compiled into a "Collection" (see: folder-collections). You will note that I
had to comment out some of the definitions from the beginning of each tune
file and move them to the collection file in order to avoid errors.

I then wanted to apply this construct to Piobaireachd tunes which are more
complex and required use of user-defined music variables (see folder
Piobaireachd). That is when I ran into trouble because it would appear that
all these user-defined music variables would also have to be lifted out of
the Piobaireachd files and placed at the beginning of the collection file.
As I said before this seemed a very clumsy thing to do making my collection
file enormous and difficult to read.  

You may be right in which case I will have to study your construct and apply
it to my Piobaireachd tunes, however, I was hoping for a simpler solution.
If you cannot see one then I suppose I must bite the bullet but I'm not very
code literate so it may take time to affect the change.




-
John McWilliam
--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Variables-when-compiling-a-book-tp171346p171369.html
Sent from the User mailing list archive at Nabble.com.

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


Re: Variables when compiling a book

2015-02-03 Thread Christopher R. Maden
On 02/03/2015 08:58 AM, John McWilliam wrote:
> You may be right in which case I will have to study your construct 
> and apply it to my Piobaireachd tunes, however, I was hoping for a 
> simpler solution. If you cannot see one then I suppose I must bite 
> the bullet but I'm not very code literate so it may take time to 
> affect the change.

Refactoring can be kind of annoying, but like any other kind of
infrastructure work, there comes a time when you can’t avoid it, and
it’s satisfying once it’s done.

A simple way to get started: If you use the same construct in two
different files, put it in its own file and \include it where you need
it, for example:

> all these user-defined music variables would also have to be lifted
> out of the Piobaireachd files and placed at the beginning of the
> collection file.

If these are used everywhere, then that makes sense to do.

If they are not, e.g. if they represent passages of music, then you can
leave them in situ.

Another way to think about this is that some LilyPond instructions
define things, and others do things.  E.g.:

theNotes = { c4 c c c }

defines a variable; it doesn’t make LilyPond generate any output.

\score { \theNotes \layout {} }

causes LilyPond to generate a PDF with some content.

If you want to reuse files, don’t mix these two kinds of things.

To go back to my example, atholl_highlanders_tune.ly defines a lot of
variables, but if you run LilyPond on it, there’s no output.  Meanwhile,
atholl_highlanders.ly and crism_tunes.ly both \include
atholl_highlanders_tune.ly, so that they have access to all the music
defined therein, but there’s no music defined in those files themselves,
just output.

It’s a bit of a pain in the neck to set up, but once you do, adding new
tunes is much, much easier.

~Chris
-- 
Chris Maden, text nerd  http://crism.maden.org/ >
Surround hate and force it to surrender.
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9  A210 4A51 DBAC 5C5C 3D5E

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


Re: Variables when compiling a book

2015-02-03 Thread Knute Snortum
We at Mutopia.org have been struggling with the same issues, except that we
have the extra condition that each separate piece in the collection should
also compile on its own.  You can see our "flayelings" here:
https://github.com/ksnortum/mp-sandbox


Knute Snortum
(via Gmail)

On Tue, Feb 3, 2015 at 7:10 AM, Christopher R. Maden 
wrote:

> On 02/03/2015 08:58 AM, John McWilliam wrote:
> > You may be right in which case I will have to study your construct
> > and apply it to my Piobaireachd tunes, however, I was hoping for a
> > simpler solution. If you cannot see one then I suppose I must bite
> > the bullet but I'm not very code literate so it may take time to
> > affect the change.
>
> Refactoring can be kind of annoying, but like any other kind of
> infrastructure work, there comes a time when you can’t avoid it, and
> it’s satisfying once it’s done.
>
> A simple way to get started: If you use the same construct in two
> different files, put it in its own file and \include it where you need
> it, for example:
>
> > all these user-defined music variables would also have to be lifted
> > out of the Piobaireachd files and placed at the beginning of the
> > collection file.
>
> If these are used everywhere, then that makes sense to do.
>
> If they are not, e.g. if they represent passages of music, then you can
> leave them in situ.
>
> Another way to think about this is that some LilyPond instructions
> define things, and others do things.  E.g.:
>
> theNotes = { c4 c c c }
>
> defines a variable; it doesn’t make LilyPond generate any output.
>
> \score { \theNotes \layout {} }
>
> causes LilyPond to generate a PDF with some content.
>
> If you want to reuse files, don’t mix these two kinds of things.
>
> To go back to my example, atholl_highlanders_tune.ly defines a lot of
> variables, but if you run LilyPond on it, there’s no output.  Meanwhile,
> atholl_highlanders.ly and crism_tunes.ly both \include
> atholl_highlanders_tune.ly, so that they have access to all the music
> defined therein, but there’s no music defined in those files themselves,
> just output.
>
> It’s a bit of a pain in the neck to set up, but once you do, adding new
> tunes is much, much easier.
>
> ~Chris
> --
> Chris Maden, text nerd  http://crism.maden.org/ >
> Surround hate and force it to surrender.
> GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9  A210 4A51 DBAC 5C5C 3D5E
>
> ___
> 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