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. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
