Re: An idea for a systematic development of a large score.

[Shevek]

I do all of my composing in Lilypond, and have completed numerous large
ensemble projects of significant length. I'd estimate I've written around
20,000 lines of Lilypond and Scheme code in the last two years. My preferred
file structure continues to evolve, but it is basically the following:

Project folder:
* project_score.ly
* project_parts.ly
* project.ly
* project_lib.ily

/home/me/.lily/:
* macros.ily
* orchestral_style.ily
* macros/

It's pretty self-explanatory. I include \version and \language in every
Lilypond file, without exception. I define all of my music variables in
project.ly, including global. I prefer this to having a file for each
instrument, because it makes keeping track of versions easier; I suppose if
I used a version management system, that wouldn't be a problem, but at the
moment I just put ascending numbers at the end of the file name :p. I use a
standardized naming convention for variable names, quote names, and context
names. I always define \global first, then I go in score order, say \fluteI,
\fluteII, etc. I do not use music variables for motives or themes: I
explicitly write all of my music from beginning to end, and I use \transpose
and \transposition to write all instruments in concert pitch. 

At the end of project.ly, I \addQuote for \fluteI, \fluteII, all the way
through the variables in score order. That allows me to use \cueDuring when
I make instrumental parts. I make copious use of \tag and \removeWithTag,
for example to include enharmonic key changes in transposing parts, for
overrides that are only to be used in score or in parts, and to exclude
nested contexts like chord symbols or divisi staves from \addQuote.

In larger projects, editing project.ly can get cumbersome if each variable
is 1,000 lines long; suppose I want to change a note in measure 67 in
\fluteII and \violinI? To make editing easier, I break the variables up into
\fluteIsectionA, \fluteIsectionB, etc. The project.ly file then starts with
all of the sectionA variables in score order, then all the sectionB
variables in score order, etc. In such projects, I use an additional file
called project_form.ly, which \include's project.ly, and which defines the
variables \fluteI, \fluteII, etc., using the sectional variables. I wouldn't
recommend using this kind of scheme except in very large projects, because
things get hairy when one instrument has a crescendo over the break between
sections. It is better to write all of the music for each instrument in a
single variable.

I use \bookpart to keep the \score expressions for all of my instrumental
parts in one file. This also has the advantage that I get a single PDF of
all of the parts. I begin this file with a global \layout block, which
allows me to easily apply overrides to all the parts at once.

I have a multi-layered system for reusing snippets and style information.
The most basic level is, of course, overrides in the project.ly,
project_score.ly, or project_parts.ly files. The next layer is the
project_lib.ily file, which includes the \header block for the project, the
title and front-matter markup, a \layout block of project-specific but
project-wide overrides, and any snippets or macros that I only want to use
in this project. When I use a snippet from LSR for the first time, I almost
always copy and paste it into a project_lib.ily file. Macros that I
frequently redefine for different projects, like \mute (will it be "mute" or
"senza"?) also go in project_lib.ily.

Anything that I want to reuse between projects goes in the .lily folder,
which I have added to my Lilypond path. macros.ily includes short snippets
and miscellaneous macros, such as common \once\override's and a list of
common markup expressions. It also \include's all of the files in the
.lily/macros folder. The files in the macros folder are longer snippets or
collections of snippets related to a common task, such as jazz notation. The
other files in .lily are stylesheet files like orchestral_style.ily or
chamber_style.ily, which contain \layout blocks with most of the overrides I
use, custom contexts, etc. I am fairly conservative about adding or removing
things from my stylesheets, since they each apply to many projects. Instead,
I can contradict the stylesheet with overrides in project_lib.ily, as long
as I \include "project_lib.ily" after I \include "orchestral_style.ily."



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/An-idea-for-a-systematic-development-of-a-large-score-tp146017p146032.html
Sent from the User mailing list archive at Nabble.com.