Selected Topics
Proposal for a new method of Generating Lilypond Files from ABC files
I have been using a fairly complicated lilypond script to find and convert .abc music files to what amounts to a starting point for a Lilypond music file. I say starting point, because the file needs a significant amount of editing before it can be considered to be useable. 'Useable' in this context means that it can be compliled to .pdf sheet music and accompanying MIDI files. It becomes annoying that after spending a fair bit of time getting the music correct in .abc format, I have to do all this front work to get it right for lilypond.
The issue is simply this; we are talking about two quite different music encoding languages, and, what with music itself being quite complex, with a multitude of facets, and with each of the two languages involved having their own quirks, it is difficult enough to convert from one to the other without the added difficulty of the quirkiness creating errors along the way. It is very difficult to identify the source of potential errors when in fact we are dealing with two completely different processes;
- Parsing the input file - identifying the individual musical elements in sequence.
- Encoding the extracted musical elements in the output file format.
This new method proposes to separate these two processes, creating an intermediate file describing the extracted musical elements in an English-language format. As I thought about the need for this, I realized that in fact, I had already done a fairly large portion of this in the original script, which is already a two-stage process. This simply formalizes the process, and provides for more consistency. I think I may also use the effort to learn another computer language, perhaps JavaScript,.. but initially, the need is for the definition of the new music file format - let's call it "Descriptive Language for Music", or DLM for short, and use the file extension '.dlm'
Music Notation and Definitions: Now, music description languages, such as ABC and lilypond are designed to document or replicate a printed sheet of music, so let's start by describing that. I've done this on a separate page; Selected Topics: Musical Definitions for clarity. Likewise, I've placed the next topic, Western Music Notation on it's own page.
Sheet Music Structure: So if you look at a piece of sheet music, you will note that they generally consist of three components; 1. Heading information - the title, author, type of music, etc.; 2. Music - on one staff or several, sometimes combined with lyrics tied to the notes, and; 3. (optionally) A textual portion at the end, usually song notes and the Lyrics. In addition to this structural layout, the music itself will consist of a logical arrangement. 1. One or more staves - each set arranged as a 'system', where staves that are played together (i.e. at the same time) are visually tied together by tie lines, with the bar lines of each lining up vertically. The notes are arranged choronologically, and obey well-defined rules for beaming and quantity per bar, tied to the time signature. Each staff will (at least initially) have an clef symbol, a key signature, and a time signature. An so on. And music files all attempt to capture all this information so that a piece of music can be regenerated in the same format as the original (the assumption here is that the original is a piece of sheet music on paper, not necessarily the case, but usually).
Music File Inconsistencies: And so I intend to create my music file format to do the same thing; encapsulate and capture the various components from an input file, so that they can be formatted appropriately for an output file. Unfortuantely, it is right here where we start to run into problems. A specific example of an inconsistency between ABC format and lilypond format is that ABC requires lyrics that are in the music section (i.e. underneath each staff) to be interleaved with the music definition itself (much like the sheet shows it), whereas lilypond requires that it be defined separately, combined (if desired) in an operation defined at the end of the file. Note that these two methods are not (necessarily) inconsistent, as in each case the lyrical sylables are tied to a beat (note) in the music; in other words, they are already tied structurally, so don't require the structural tie that ABC imposes. Note however, that this brings up another inconsistency that actually does need to be dealt with; ABC considers every note to be a beat, even the tied and slurred ones, and so require that the extra beat be taken care of in the lyrics definition. Lilypond allows for beats to be skipped (melissmas), but considers ties and slurs to be single beats, and therefore don't need the lyrics to take care of it.
File Testing: Another issue that will need to be taken care of is driven by one of the main characteristics, one might say advantages of, ABC files - they are very flexible and forgiving. As an example, the number of beats per bar is defined by the time signature, which tells you how many (the top number) notes of what duration (the bottom number), or an equivalent combination of the same duration are required to occupy each bar. ABC assumes that the person coding the file is responsible for enforcing that rule, and does no checking - it will happily put as many notes in a bar as the file is asking for. Lilypond, on the other hand, creates the bars itself, and will therefore not print the desired result if the notes defined are the wrong duration (it does provide a mechanism to assist in checking each individual bar, using the same symbol that ABC uses to generate a bar symbol; the "|"). So a mechanism should be provided to ensure the bars defined in an input file have valid duration, and otherwise meet the logical and structural requirements of music notation that may or may not be enforced in the creation of the input file.
DLM File Sections: Given that all music is defined by the three sections described above (Heading, Music, and Text), I will define my DLM file in the same way. Note that, much like lilypond, I am not so concerned with capturing what the music looks like, but rather capturing the definition of the music itself. As a result, I can ignore any input features that deal only with the visual presentation, but definitely need to capture any that affect the audio presentation, such as tempo. So to start, my file structure will consist of three sections, indicated by a key phrase;
[Heading] (logical heading information, such as title, composer, etc.) [Music] (text defining the music) [Text] (text - notes, lyrics, etc.)
Structure: It's obvious that this structure lends itself to doing a 3-pass interpretation of an input file, where only information belonging in each step is dealt with.
Use PERL for now: Now, I know I said I'd like to take this opportunity to aid in learning a new language, but I am very impatient, and; I already know perl, and I've already done a lot of this work in my existing tools, so I think that for the moment I will continue in the same vein.
Modular Perl: Reviewing my existing perl files, I remember that my abc2ly script runs in several stages already. Like many of my perl scripts, I use a generic startup section that provides for a help listing, various operating modes based on command-line options, and a facility to operate on either a single file, or on a specified folder. At this point, I realize that it will be painful to dig through that very large script file, and make the changes I want, which tells me that I need to modularize the code, starting with this very front-end portion.