[icon]

GNU LilyPond

-- --

What is LilyPond
Home
Examples
Templates
Download
GNU/Linux binaries
Windows binaries
Source code
Documentation
Tutorial
Manual
Glossary
Index

Support
Mailing lists
Search
WikiWiki

External sites
lilypond.org/stable
lilypond.org/development
savannah.gnu.org
ftp.lilypond.org
Mutopia
Other music online

Music representation

One of the big questions when making programs, is what kind of input the program should expect. Many music notation programs offer a graphical interface that shows notation, and allow you to enter the music by placing notes on a staff. Although this is a obvious way to design a program, from our point of view, it is cheating. After all, the core message of a piece of music notation simply is the music itself. If you start by offering notation to the user, you have already skipped one conversion, even if it is implicit. If we want to generate music notation from something else, then the obvious candidate for the source is the music itself.

On paper this theory sounds very good. In practice, it opens a can of worms. What really is music? Many philosophical treatises must have been written on the subject. Even if you are more practically inclined, you will notice that there exist an enormous number of ways to represent music in a computer, and they are much more incompatible than the formats for word processors and spreadsheets. Anyone who has tried to exchange data files from between different notation programs can attest to this.

This problem is caused by the two-dimensional nature of music: in polyphonic music, notes have time and pitch as their two coordinates, and they often are related in both directions. Computer files on the other hand are essentially one-dimensional: they are a long stream of characters. When you represent music in a file, then you have to flatten this two-dimensional information breaking either timing or pitch relations, and there is no universal agreement on how to do this.

Fortunately, we have a concrete application, so we don't run the risk of loosing ourselves in philosophical arguments over the essence of music. We want to produce a printed score from a music representation, so this gives us a nice guide for designing a format: we need a format containing mainly musical elements, such as pitch and duration, but also enough information to print a score. Our users have to key in the music into the file directly, so the input format should have a friendly syntax. Finally, we as programmers and scientists want a clean formal definition. After all, producing music notation is a difficult problem, and in the scientific world, problems can only be solved if they are well-specified. Moreover, formally defined formats are easier to write programs for.

These ideas shaped our music representation: it is a compact format that can easily be typed by hand. It complex musical constructs from simple entities like notes and rests, in much the same way that one builds complex formulas from simple expressions such as numbers and mathematical operators. The strict separation between musical information and typesetting also gives a blueprint of the program: first it reads the music representation, then it interprets the music--reading it `left-to-right', and translating the musical information to a layout specification. When the layout is computed, the resulting symbols are written to an output file.

Go back to index of LilyPond.

Please send GNU LilyPond questions and comments to lilypond-user@gnu.org.

Please send comments on these web pages to (address unknown)

Copyright (c) 1997--2002 Han-Wen Nienhuys and Jan Nieuwenhuizen.

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.


This page was built from LilyPond-1.7.14 (development-branch) by

Buchan Milne <(address unknown)>, Thu Mar 6 21:11:35 2003 CET.