=head1 NAME

MANIFESTO -- Rationale behind the GNU LilyPond project

=head1 DESCRIPTION


GNU LilyPond was written with some considerations in mind:


=over 4

=item *

Describing a well-defined language for defining music. We call
this language (rather arrogantly) The Musical Definition Language
(mudela for short). GNU LilyPond reads a mudela sourcefile and outputs a
TeX file.  

=item *

We want to provide an easy-to-use interface for typesetting music in
its broadest sense. This interface should be intuitive from a musical
point of view. By broadest sense we mean: it is designed for music
printed left to right in staffs, using notes to designate rythm and
pitch.

=item  *

Generate high-quality output. Ideally it should be of a professional
quality. We'd like to render Herbert Chlapiks words, "Fine music
setting is not possible without a knowledgeable printer,"  untrue.

=item *

Make a system which is fully tweakable. It should be possible to
typeset a book on how not to typeset music.

=back 

=head1 LILYPOND


Further considerations while doing the programming

=over 4

=item *

GNU LilyPond uses MusiXTeX fonts and TeX for its output. This is not a key
issue: in a future version, GNU LilyPond might bypass TeX, but at the moment
TeX is convenient for producing output.

=item *

GNU LilyPond does not display notes directly, nor will it be rehacked to be
used interactively. GNU LilyPond writes output to a file.  It will not be
extended to play music, or to recognize music.

=item *

GNU LilyPond is intended to run on Unix platforms, but it should
be portable to any platform which can run TeX and the GNU tools

=item *

GNU LilyPond is free. Commercial windows packages for setting music are
abundant. Free musicprinting software is scarce.

=item *

GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit
broken systems.

=back

=head1 MUDELA

The design of Mudela has been (perfect past tense, hopefully) an
ongoing process, the most important criteria being:

=over 4

=item *

define the (musical) message of the composer as unambiguously as possible.

This means that, given a piece Mudela, it should be possible for a
program to play a reasonable interpretation of the piece.

It also means that, given a piece of Mudela, it should be possible for a
program to print a score of the piece.

=item *

be intuitive, and easily readable (compared to, say, Musi*TeX input,
or MIDI :-),

=item *

be easily writable in ASCII with a simple texteditor, yfte(TM).

=back

Other considerations were (and will be):

=over 4

=item *

be able to edit the layout without danger of changing the original
music (Urtext),

=item *

allow for adding different interpretations, again, 
without danger of changing the original,

=item *

easy to create a conductor's score, 
as well as the scores for all individual instruments,

=item *

provide simple musical manipulations, such as 
S<(i) extracting> a slice of music from a previously defined piece, 
S<(ii) extracting> only the rhythm from a piece of music, 
S<(iii) transposing>, etc.,

=item *

easy to comprehend to both programmers and others.

=back

One of the things that (might) be here would be: feasible to use in a
graphic editor. We don't have experience with these beasts, so we
don't know how to do this. Comments appreciated.

Musical pieces could be

=over 4

=item *

Mahlerian orchestral scores,

=item *

piano pieces (Schubertian, Rachmaninovian),

=item *

pop songs (lyrics and chords),

=item *

gregorian chants,

=item *

Bach multivoice organ pieces,

=item *

Short excerpts to be used in musicological publications.

=back
