Re: Standard LilyPond score structure (Was: How do new users feel about LilyPond's documentation?)

[H. S. Teoh]

On Thu, Apr 23, 2015 at 04:19:08AM +0200, Gilles wrote:
> On Wed, 22 Apr 2015 21:53:42 -0400, Kieren MacMillan wrote:
[...]
> >So, to output a simple 16-bar lead sheet, a user should always [be
> >forced to] create 3 files (voice.ily, chords.ily, score.ly)? Or maybe
> >four (lyrics.ily)? Or more?
> >Because a “one-per-instrument” file structure — or something equally
> >segmented in some other way — is likely necessary (or at least
> >desirable enough to be chosen as the standard) for a huge project
> >like an opera.
> 
> Yes! :-)
> But once there is a standard, many tools will blossom, in particular
> one that would offer "simple layout" and transparently transform into
> "standard layout"...
>
> Or more probably a user that is too lazy to set up one directory
> (rather than one file) for a given project is likely to use a GUI in
> the first place and will never ever see the multi-file standard
> layout.
[..]

I beg to differ. I do not use a GUI (and never will, for lilypond), yet
I have found (so far) that I prefer the single-file approach. At least,
I've found it quite manageable so far for single-movement pieces.

I would likely consider splitting it into multiple files for longer
(multi-movement) works, but Kieren's layout (voice.ily, chords.ily,
score.ly, etc.) doesn't fit very well with my work habits, so I would
hate to be forced to use it. I find that sprinkling stuff across
multiple files is the best way to get totally lost when I need to do
some complicated edits, like move passages around the score, since I
then have to keep track of which file(s) I'm moving information from,
which file(s) I'm moving to, and where (within each file) they need to
go. Keeping in a single file (properly structured, of course!) makes it
simpler -- I only need to keep track of where in the file to move from
and where to move to.

Now having said that, I haven't perused that many lilypond input files,
but in my own files I find that I'm tending towards a highly structured
format -- single variables for entire instrument parts, and within each
variable, labels (in comments) for every passage that is consistently
applied across all parts, and groupings of bars into paragraphs in the
input, usually in blocks of 4 lines (1 bar per line) under each passage
label. This makes navigating within the part much more tractable, since
you can scan blocks of 4 or 8 bars at a time rather than count
individual bars. I even apply this structure to long rests -- instead of
R1*50 (or however many bars it is), I break it up into groups under
passage labels, and within each passage label groups of R1*4 or R1*8 or
some multiple thereof, separated by blank lines. Again, this greatly
facilitates navigating within the part when I need to, for example,
insert notes somewhere in the middle of what used to be a long multibar
rest -- I identify the passage by label and count blocks (which are
matched across all parts, btw) instead of counting individual bars,
which would be very error prone.

As for identifying which passage something is in, the \global variable
conveniently serves as an "index" of passage labels in addition to
holding things like tempo changes and time/key signatures, since it also
conforms to the aforementioned labelling / blocking structure.

Of course, this precludes using variables for (partial) passages, but I
find that's actually a plus, because otherwise navigating quickly
becomes intractible (it gets worse if the variable can be defined in any
of a large number of files and/or is reused in many different places).
For doubled passages, I find that cut-n-paste works better than the
tempting way of "factoring out" common notes into a variable, since it
lets you edit the notes just for that part without inadvertently
affecting all parts that use that variable.

In any case, some manner of structure is clearly necessary, whether you
have a single input file or multiple input files.


T

-- 
Bomb technician: If I'm running, try to keep up.