I already separate notes from layout, since I want to layout the same notes in chorus only, chorus with piano reduction, maybe others. But, I also want to compile parts one at a time, as well as together.
Currently, I have 22-Behold_the_Lamb_of_God-chorus.ly 22-Behold_the_Lamb_of_God-music-words.ly 37-The_Lord_Gave_the_Word-chorus.ly 37-The_Lord_Gave_the_Word-music-words.ly 47-Behold_I_Tell_You_a_Mystery-chorus.ly 47-Behold_I_Tell_You_a_Mystery-music-words.ly Too_Hot_to_Handel-chorus.ly Too_Hot_to_Handel-style.ly where each of the *-chorus.ly files \includes the *-style.ly file. All notes and lyrics are in the *-music-words.ly files, and all layout in the *-chorus.ly files, with globally used definitions and parameter settings in Too_Hot_to_Handel-style.ly. Too_Hot_to_Handel-chorus.ly includes each of the other *-chorus.ly files to put together the whole thing (there are 10 more numbers to go, and the initial numbers come from Handel's whole work, only part of which is in this arrangement). Each indivdual number is a \bookpart. I will add piano reductions, and any other parts I decide to set, to the same *-music-words.ly files. Then, I will create things like 22-Behold_the_Lamb_of_God-chorus-piano.ly and Too_Hot_to_Handel-chorus-piano.ly with appropriate layout. There are plenty of good reasons to be able to produce individual numbers without even compiling the whole thing, and plenty of good reasons to avoid editing the files as much as possible when producing different variations (i.e., just selecting the right top-level file, not editing other files). I could have a skeleton output producer for each number, similar to the skeleton output producer for the whole collection. E.g. 22-Behold_the_Lamb_of_God-chorus-outputSkeleton.ly might contain only \include "Too_Hot_to_Handel-style.ly" \include "22-Behold_the_Lamb_of_God-chorus.ly" but that is unnecessarily indirect. Many other languages, including most programming languages, and also the LaTeX typesetting system, have recognized the value of declaring in file A that it requires file B, and automatically including B if it has not already been included by another such requirement. There's a whole lot of experience showing that this is the better way to go than multiplying the skeleton files. I am confident that I could implement it as a Scheme function in LilyPond, but I hope that someone has already done it. Thanks, Mike O'Donnell James Bailey wrote: > > On 21.01.2010, at 18:47, Michael J. O'Donnell wrote: > >> Is there a standard way to make sure that a file full of LilyPond style >> definitions is included just once, no matter how many times it is >> mentioned? >> >> I searched the Web site, mail archives, and /usr/shar/lilypond for >> "include once" and "include guard", to no avail. With the C >> preprocessor, there is a standard trick for setting and testing a >> variable to disable all but the first attempt to include a header file. >> Some languages have an "include-once" command. >> >> I am putting together a large choral score from bookparts for each >> number in the work. I like to be able to produce either a single number, >> or the whole score. The natural approach is to include style definitions >> in each of the files that I might set, including the file to format the >> whole score and the files to format individual numbers. Files to format >> individual numbers also include the style definitions. >> >> I find that repeated inclusion of the same definitions leads quickly to >> a segmentation fault. >> >> I can either add one more level of indirection, with one more file per >> number. Or, I can do some Scheme hacking, with a global variable to set >> showing inclusion (tricky, because the variable needs to be testable >> reliably even when it has never been set explicitly). >> >> But, I'd prefer to use a well-known standard method, if it exists. >> >> Thanks, >> >> Mike O'Donnell >> > > One solution might be to have either notes or layout definitions in a > file, but not both. It quickly leads to large amounts of files, but > you can have separate book files which create the actual parts, and > not have multiple includes. > _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
