|
From: | Carl Sorensen |
Subject: | Re: Time bracket notation for very large scale compositions |
Date: | Fri, 9 Apr 2021 19:34:57 +0000 |
User-agent: | Microsoft-MacOutlook/10.10.1b.201012 |
From:
lilypond-user <lilypond-user-bounces+carl.d.sorensen=gmail.com@gnu.org> on behalf of AHF <culver@anarchicharmony.org> Hello LilyPeople, I am looking into using LilyPond for future works. What I like about it is the text input, which makes it very easy to integrate with the collection of C programs and PostgreSQL functions I use to generate and manage
music for large-scale pieces. (I’m on a Mac.) I have been doing this since the late 1980’s, for John Cage's operas, installations, and films, and for my own large-scale orchestral works, such as “Ocean 1-133” for 150 musician soloists over 90 minutes — see
the Merce Cunningham work “Ocean" if you are interested. The parts for Ocean 1-133 (more than 3000 pages) were pulled from the database and formatted using C code into the P-field file format of the wonderful old Score program by Leland Smith. Like LilyPond, this format
is expressed with simple text files. Given the abandonment of Score and the vibrancy of LilyPond, I want to know if I should be using LilyPond. The example below is from one of Cage’s Number pieces, demonstrating Time Bracket notation. The important challenges for a notation program are: - Each time bracket is centered on the page, and the system is only as long as necessary. This should be no problem at all. You will create a lilypond score inside of a markup that is centered. - No barlines. No barlines is trivial. - Notes within the time bracket are distributed evenly horizontally. There is no notion of tempo or meter. It is pretty easy to get even distribution using strict proportional spacing. You will need to use a constant duration of notes to make this work. - Whole note noteheads - or any notehead I want, free of any metric constraints. Any notehead can be put on a note of any duration, so it is possible to do this while achieving the proportional spacing above. - Ample vertical spacing between time bracket systems. Very easy – lilypond has configurable automatically variable or fixed spacing of systems on a page. - Horizontally centered headers and footers (not shown). Very easy - Sometimes one piece runs over several pages (a “piece” is a set of time brackets for one player). Trivial – LilyPond will handle this no problem. Score had no problem doing this because fundamentally it was a CAD program augmented by musical knowledge. With the P-field format, you essentially cut out the musical knowledge layer. You got to put beautiful-looking
music symbols wherever you wanted them. From what I can tell, the musical knowledge part of the equation is too deeply baked in to most notation programs, such that if you don’t need it, or want to invent new rules, you are stuck trying to trick the program
into not doing what it “helpfully” insists on doing. Lilypond is very strongly based on musical knowledge. It is not a CAD program at heart. I think that if you try to explicitly govern the physical position of each bit of notation on the page, you will have difficulty. However, the musical knowledge layer is in the form of LilyPond engravers. And engravers are easy to remove and replace with other engravers. So you could make engravers that would capture the new rules you would like to implement. I need to be able to generate 100% of the .ly files from C, taking as a source the composition in the database (which was also generated, using chance operations, with C code). Because of the volume of pages, hand
tweaking the parts is not an option. That is completely doable. So:
Yes, as long as you can capture the specialized layout rules you want to use in custom engravers.
With LilyPond, there are always multiple ways to achieve something, so it’s not trivial to answer this particular question.
LilyPond will not allow you to specify absolute location for musical symbols, in general. But the fix is not to “fool” it into compliance. Rather it is to build in the compliance.
If you do it by replacing existing engravers with new custom engravers, it’s not a workaround. Future versions should not break your custom engravers, and hence should not break your existing code. As an extra point, it is easy to keep multiple versions of LilyPond on your system, and it is possible to choose the version to use based on the lilypond \version string in the file. If you do this, you do not need to worry about breakage
at all – you can regenerate your score anytime you like. I would assume that your C-based input file creation tools would easily be capable of generating a \version string indicating the version of lilypond they are designed for. BTW, I am open to hiring a knowledgeable LilyPerson as a time-saving and inspirational resource. Reply to this email if you are interested. There are multiple people on the list that might be interested. HTH, Carl |
[Prev in Thread] | Current Thread | [Next in Thread] |