+++ /dev/null
-LilyPond è il programma di notazione musicale del progetto
-GNU. Questo programma può generare delle ottime partiture musicali
-a partire da un file contenente la descrizione della musica. Può
-anche generare esecuzioni meccaniche della partitura in formato
-MIDI. Le caratteristiche del programma includono un versatile
-linguaggio di descrizione musicale, pentagrammi multipli, segni di
-divisione, chiavi, tasti, parole, cadenze, legature, acciaccature,
-terzine, segni di formattazione ed estrazione delle parte. Nella
-distribuzione è compreso anche un fort di simboli musicali.
-
+++ /dev/null
-COMMENT(silly... DEFINEMACRO(pic)(1)(url(ARG1)(ARG1.png)))
-DEFINEMACRO(pic)(1)(verbinclude(ARG1.in))
-
-nsect(LilyPond è il tipografo musicale del progetto GNU. )
-
-includefile(COPERTINA.in)
-nl()
-
+++ /dev/null
-report(CodingStyle - standards while programming for GNU
-LilyPond)(Han-Wen Nienhuys and Jan Nieuwenhuizen)()()
-
-nsect(DESCRIPTION)
-
-We use these standards while doing programming for GNU LilyPond. If
-you do some hacking, we appreciate it if you would follow this rules,
-but if you don't, we still like you.
-
-Functions and methods do not return errorcodes.
-
-quote(
-
-A program should be light and agile, its subroutines
-connected like a string of pearls. The spirit and intent of
-the program should be retained throughout. There should be
-neither too little nor too much, neither needless loops nor
-useless variables, neither lack of structure nor overwhelming
-rigidity.
-
-A program should follow the 'Law of Least
-Astonishment'. What is this law? It is simply that the
-program should always respond to the user in the way that
-astonishes him least.
-
-A program, no matter how complex, should act as a
-single unit. The program should be directed by the logic
-within rather than by outward appearances.
-
-If the program fails in these requirements, it will be
-in a state of disorder and confusion. The only way to correct
-this is to rewrite the program.
-
--- Geoffrey James, "The Tao of Programming"
-)
-
-
-nsubsect(LANGUAGES)
-
-C++, /bin/sh and Python are preferred. Perl is not.
-Python code should use an indent of 8, using TAB characters.
-
-nsubsect(FILES)
-
-Definitions of classes that are only accessed via pointers
-(*) or references (&) shall not be included as include files.
-
-filenames
-
-verb(
- ".hh" Include files
- ".cc" Implementation files
- ".icc" Inline definition files
- ".tcc" non inline Template defs
-)
-
-in emacs:
-
-verb(
- (setq auto-mode-alist
- (append '(("\\.make$" . makefile-mode)
- ("\\.cc$" . c++-mode)
- ("\\.icc$" . c++-mode)
- ("\\.tcc$" . c++-mode)
- ("\\.hh$" . c++-mode)
- ("\\.pod$" . text-mode)
- )
- auto-mode-alist))
-)
-
-
-The class Class_name_abbreviation is coded in file(class-name-abbr.*)
-
-
-nsubsect(INDENTATION)
-
-in emacs:
-
-verb(
- (add-hook 'c++-mode-hook
- '(lambda() (c-set-style "gnu")
- )
- )
-)
-
-If you like using font-lock, you can also add this to your file(.emacs):
-
-verb(
- (setq font-lock-maximum-decoration t)
- (setq c++-font-lock-keywords-3
- (append
- c++-font-lock-keywords-3
- '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
- ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
- ))
-)
-
-nsubsect(CLASSES and TYPES:)
-
-verb(
- This_is_a_class
-)
-
-nsubsect(MEMBERS)
-
-verb(
- Class::member ()
- Type Class::member_type_
- Type Class::member_type ()
-)
-
-the code(type) is a Hungarian notation postfix for code(Type). See below
-
-nsubsect(MACROS)
-
-Macros should be written completely in uppercase
-
-The code should not be compilable if proper macro declarations are not
-included.
-
-Don't laugh. It took us a whole evening/night to figure out one of
-these bugs, because we had a macro that looked like
-code(DECLARE_VIRTUAL_FUNCTIONS ()).
-
-nsubsect(BROKEN CODE)
-
-Broken code (hardwired dependencies, hardwired constants, slow
-algorithms and obvious limitations) should be marked as such: either
-with a verbose TODO, or with a short "ugh" comment.
-
-nsubsect(COMMENTS)
-
-The source is commented in the DOC++ style. Check out doc++ at
-lurl(http://www.zib.de/Visual/software/doc++/index.html)
-
-verb(
- /*
- C style comments for multiline comments.
- They come before the thing to document.
- [...]
- */
-
-
- /**
- short description.
- Long class documentation.
- (Hungarian postfix)
-
- TODO Fix boring_member ()
- */
- class Class {
- /**
- short description.
- long description
- */
-
- Data data_member_;
-
-
- /**
- short memo. long doco of member ()
- @param description of arguments
- @return Rettype
- */
- Rettype member (Argtype);
-
- /// memo only
- boring_member () {
- data_member_ = 121; // ugh
- }
- };
-)
-
-
-Unfortunately most of the code isn't really documented that good.
-
-
-nsubsect(MEMBERS (2))
-
-Standard methods:
-
-verb(
- ///check that *this satisfies its invariants, abort if not.
- void OK () const
-
- /// print *this (and substructures) to debugging log
- void print () const
-
- /**
- protected member. Usually invoked by non-virtual XXXX ()
- */
- virtual do_XXXX ()
-
- /**add some data to *this.
- Presence of these methods usually imply that it is not feasible to this
- via a constructor
- */
- add (..)
-
- /// replace some data of *this
- set (..)
-)
-
-nsubsect(Constructor)
-
-Every class should have a default constructor.
-
-Don't use non-default constructors if this can be avoided:
-
-verb(
- Foo f(1)
-)
-
-is less readable than
-
-verb(
- Foo f;
- f.x = 1
-)
-
-or
-
-verb(
- Foo f(Foo_convert::int_to_foo (1))
-)
-
-nsect(HUNGARIAN NOTATION NAMING CONVENTION)
-
-Proposed is a naming convention derived from the so-called
-em(Hungarian Notation). Macros, code(enum)s and code(const)s are all
-uppercase, with the parts of the names separated by underscores.
-
-nsubsect(Types)
-
-description(
-dit(code(byte))
- unsigned char. (The postfix _by is ambiguous)
-dit(code(b))
- bool
-dit(code(bi))
- bit
-dit(code(ch))
- char
-dit(code(f))
- float
-dit(code(i))
- signed integer
-dit(code(str))
- string class
-dit(code(sz))
- Zero terminated c string
-dit(code(u))
- unsigned integer
-)
-
-nsubsect(User defined types)
-
-verb(
- /** Slur blah. blah.
- (slur)
- */
- class Slur {};
- Slur* slur_p = new Slur;
-)
-
-nsubsect(Modifiers)
-
-The following types modify the meaning of the prefix.
-These are preceded by the prefixes:
-
-description(
-dit(code(a))
- array
-dit(code(array))
- user built array.
-dit(code(c))
- const. Note that the proper order is code(Type const)
- i.s.o. code(const Type)
-dit(code(C))
- A const pointer. This would be equivalent to code(_c_l), but since any
- "const" pointer has to be a link (you can't delete a const pointer),
- it is superfluous.
-dit(code(l))
- temporary pointer to object (link)
-dit(code(p))
- pointer to newed object
-dit(code(r))
- reference
-)
-
-nsubsect(Adjective)
-
-Adjectives such as global and static should be spelled out in full.
-They come before the noun that they refer to, just as in normal english.
-
-verb(
-foo_global_i: a global variable of type int commonly called "foo".
-)
-
-static class members do not need the static_ prefix in the name (the
-Class::var notation usually makes it clear that it is static)
-
-description(
-dit(code(loop_i))
- Variable loop: an integer
-dit(code(u))
- Temporary variable: an unsigned integer
-dit(code(test_ch))
- Variable test: a character
-dit(code(first_name_str))
- Variable first_name: a String class object
-dit(code(last_name_ch_a))
- Variable last_name: a code(char) array
-dit(code(foo_i_p))
- Variable foo: an code(Int*) that you must delete
-dit(code(bar_i_l))
- Variable bar: an code(Int*) that you must not delete
-)
-
-Generally default arguments are taboo, except for nil pointers.
-
-The naming convention can be quite conveniently memorised, by
-expressing the type in english, and abbreviating it
-
-verb(
- static Array<int*> foo
-)
-
-code(foo) can be described as "the static int-pointer user-array", so you get
-
-verb(
- foo_static_l_arr
-)
-
-
-
-nsect(MISCELLANEOUS)
-
-For some tasks, some scripts are supplied, notably creating patches, a
-mirror of the website, generating the header to put over cc and hh
-files, doing a release.
-
-Use them.
-
-The following generic identifications are used:
-
-verb(
- up == 1
- left == -1
- right == 1
- down == -1
-)
-
-Intervals are pictured lying on a horizontal numberline (Interval[-1]
-is the minimum). The 2D plane has +x on the right, +y pointing up.
-
-
+++ /dev/null
-LilyPond is een muziekzetter. Zij maakt prachtige bladmuziek
-uitgaande van een hoog niveau beschrijving bestand. LilyPond
-maakt deel uit van het GNU Project.
+++ /dev/null
-nsect(LilyPond -- De Muziek Zetter van het GNU Project)
-
-includefile(FLAPTEKST.in)
-nl()
-
+++ /dev/null
-
-article(MANIFESTO -- Rationale behind the GNU LilyPond project)(HWN
-and JCN)()
-
-sect(Goals for LilyPond)
-
-
-GNU LilyPond was written with some considerations in mind:
-
-
-itemize(
-it() 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.
-it() Providing 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.
-it()Generating 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.
-it()Making a system which is fully tweakable. It should be possible to
- typeset a book on how not to typeset music.
-)
-
-sect(Development constraints)
-
-
-Further considerations while doing the programming
-
-itemize(
-it()GNU LilyPond uses 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.
-it()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.
-it()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
-it()GNU LilyPond is free. Commercial windows packages for setting music are
- abundant. Free musicprinting software is scarce. For more thoughts on
- this, please consult the file(gnu-music) documentation.
-it()GNU LilyPond is written in GNU C++. It will not be downgraded/ported to fit
- broken systems.
-)
-
-sect(Goals for mudela)
-
-The design of Mudela has been (perfect past tense, hopefully) an
-ongoing process, the most important criteria being:
-
-itemize(
-it()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.
-it()be intuitive, and easily readable (compared to, say, Musi*TeX input,
- or MIDI :-),
-it()be easily writable in ASCII with a simple texteditor
-)
-
-Other considerations were (and will be):
-
-itemize(
-it()be able to edit the layout without danger of changing the original
- music (Urtext),
-it()allow for adding different interpretations, again,
- without danger of changing the original,
-it()easy to create a conductor's score,
- as well as the scores for all individual instruments,
-it()provide simple musical manipulations, such as em(i) extracting a
- slice of music from a previously defined piece, em(ii) extracting
- only the rhythm from a piece of music, em(iii) transposing, etc.,
-it()easy to comprehend to both programmers and others.
-)
-
-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
-
-itemize(
-it()Orchestral scores, (eg Mahler)
-it()piano pieces (eg. Schubert, Rachmaninov),
-it()pop songs (lyrics and chords),
-it()Gregorian chants,
-it()Bach multivoice organ pieces,
-it()Short excerpts to be used in musicological publications.
-)
-
+++ /dev/null
-article(LilyPond on W32)
- (Jan Nieuwenhuizen and Jeffrey Reed)
- ()
-
-No, there's no reason to be concered, Lily should work in
-Windows-NT(/95/98?) too. The setup may not be easy or smooth. This
-document will help you getting started.
-
-sect(DISCLAIMER)
-
-If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
-will work in Windows-NT (/95/98?).
-
-We still recommend you use Unix. In particular, use GNU/Linux: We've
-been there, and we've seen it happen several times. It is bf(much)
-easier and quicker to install RedHat Linux and LilyPond than to
-obtain, compile and install all the necessary tools to compile and run
-LilyPond on Windows.
-
-``Ok, thanks for the suggestions. I can't run Linux or I don't want
-to run Unix. What can I expect?''
-
-itemize(
-it()LilyPond development is moving quite fast, and all developers use Unix.
- Newly added features may require some attention to get them to work.
-it()LilyPond depends on a number of other packages that usually are
- available on Unix boxes, but are not installed by default on Windows.
-)
-
-subsect(INSTALL)
-
-Like Yodl, LilyPond will now install/extract in a unix-like tree:
-verb(
- usr/[local/]bin/
- usr/[local/]share/lilypond/*
-)
-etc.
-
-Both Yodl and Lily run in a the unix-like Cygnus gnu-windows environment;
-hopefully Cygnus will adopt the file(/usr/[local/]) tree too.
-
-nl()
-If you really don't want usr/ in your root directory, but rather scatter
-your programs and packages all over your harddisk, do something like:
-verb(
- md lilypond
- cd lilypond
- unzip ../lilypond-0.1.77.exe.zip
-)
-and add file(lilypond/usr/bin) to your file(PATH) and
-file(lilypond/usr/share/lilypond) to your file(LILYINCLUDE).
-
-
-subsect(BUILDING LILYPOND)
-
-If you've received a binary release of LilyPond (file(.exe.zip)),
-you may skip the following sections.
-
-subsect(GOOD NEWS)
-
-It can be done! Occasionally, the Cygnus b19.1 cross compiler and
-utilities under GNU/Linux are used to make the binary file(.exe.zip)
-releases (some makefile hacking was needed to build this stuff). Jeffrey
-Reed tries to keep-up with LilyPond development, and is doing quite
-well. His latest release is available on
-lurl(http://home.austin.rr.com/jbr/jeff/lilypond/).
-
-subsect(UNPACKING)
-
-I have heard of such tools that think they're probably much smarter than the
-packager and thus decide for themselves that they don't need to unpack certain
-files (e.g., empty directories such as bin/out).
-
-To unpack the lilypond sources, you should do something like: verb(
- tar zxf releases/lilypond-x.y.z.tar.gz
-)
-
-subsect(ABOUT UNIX)
-
-If you're familiar with the GNU/Cygnus development package, you may skip
-this.
-
-Don't forget to set
-verb(
- /start/settings/control-panel/system/environment/system-variables:
- GCC_EXEC_PREFIX=/Cygnus/b19/H-i386-cygwin32/lib/gcc-lib/
- MAKE_MODE=UNIX
-)
-You want to run bash, while building Lily:
-verb(
- c:\bash
- bash-2.01$
-)
-The install instructions mention something like:
-verb(
- configure
- make
- make install
-)
-
-Now for a small UNIX lesson: The current working directory (cwd) is
-by default not in your PATH, like it is under DOS (for security reasons).
-Check this by looking at the output of:
-verb(
- echo $PATH
-)
-The cwd looks like code('::') or code(':.'). If it's not there, you may
-add the cwd to your path:
-verb(
- PATH=$PATH:.
-)
-or you must use './' when issuing a command in th cwd, try:
-verb(
- ./configure
- make
-)
-
-sect(LILYPOND Windows-NT Support -- by Jeffrey Reed)
-
-My point of reference comes from 15 odd years working with a variety
-of tt(UNIX) platforms. I am relatively new to Windows-NT and, even
-though I am a card carrying tt(UNIX) bigot, I am excited about the
-NT OS. My goals for lilypond are to give back to the Free Software
-Foundation a little of what they have given me over the years and to
-contribute to the lilypond project by supporting a Windows-NT port. I
-hope that someday we can distribute and run lilypond on the NT OS in a
-much more native fashion.
-
-itemize(
-it()link(Building lilypond on tt(Windows-NT))(build)
-it()link(Maintaining lilypond on tt(Windows-NT))(maintain)
-it()link(Running lilypond on tt(Windows-NT))(run)
-)
-
-
-subsect(Building lilypond on Windows-NT) label(build)
-Currently as stated above lilypond is primarily a tt(UNIX) thing.
-The Windows-NT port is based on the tt(UNIX) environment provided by
-url(Cygnus)(http://www.cygnus.com). Therefore the first step is to
-download and install the Cygnus development kit:
-
-subsubsect(Cygnus Development Kit)
-lurl(http://www.cygnus.com/misc/gnu-win32/)
-
-
-Please follow the documentation Cygnus has on there web site for
-downloading and installing. The important part is that you down load
-the entire development kit. I believe it is file(full.exe). The
-installation will ask you where you want to install it. I will refer
-to Cygnus installation directory as file(/gnuwin32/cygwin-b20). There
-should be a file(README) file that contains installation instructions.
-After the installation is complete you should have a em(Cygnus)
-shortcut in your em(Program) section of your em(Start Menu). This
-shortcut is your door to the tt(UNIX) world and I will refer to the
-resulting window as a file(bash) shell.
-
-The shortcut points to file(/gnuwin32/cygwin-b20/cygnus.bat). The
-following is my file(cygnus.bat) file.
-
-verb(
-@ECHO OFF
-rem default environment
-
-rem GNU cygnus installation
-
-SET CYGREL=B19.1
-SET MAKE_MODE=unix
-SET LOCAL_ROOT=d:\gnuwin32
-SET LOCAL_FS=d:/gnuwin32
-SET LOCAL_DIR=d:/gnuwin32/cygwin-b20
-SET CYGROOT=%LOCAL_ROOT%\cygwin-b20
-SET CYGFS=%LOCAL_FS%/cygwin-b20
-SET TCL_LIBRARY=%CYGROOT%\share\tcl8.0\
-
-rem
-rem This was not in the original but is needed by lots of packages
-rem
-SET BISON_SIMPLE=%CYGFS%/share/bison.simple
-
-rem
-rem I place the cygnus stuff in front of /WINNT
-rem
-
-SET PATH=d:\bin;%LOCAL_ROOT%\bin;%CYGROOT%\H-i586-cygwin32\bin;%PATH%
-SET MANPATH=%LOCAL_ROOT%\man;%LOCAL_ROOT%\cygwin-b20\full-man\man
-SET INFOPATH=%LOCAL_FS%/cygwin-b20/full-man/info;%LOCAL_FS%/cygwin-b20/info;%LOCAL_DIR%/info
-
-rem General tools not included with Cygnus Development Kit
-
-rem CVS
-
-SET PATH=%PATH%;%LOCAL_ROOT%\cvs-1.9.28\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/cvs-1.9.28/info
-SET MANPATH=%MANPATH%;%LOCAL_ROOT%\cvs-1.9.28\man
-
-rem EMACS
-
-SET PATH=%PATH%;%LOCAL_ROOT%\emacs-19.34\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/emacs-19.34/info
-
-rem VIM
-
-SET VIM=%LOCAL_ROOT%\vim-4.6\doc
-SET PATH=%PATH%;%LOCAL_ROOT%\vim-4.6
-
-rem TeX
-
-SET PATH=%PATH%;%LOCAL_ROOT%\texmf\miktex\bin
-
-rem a2ps
-
-SET PATH=%PATH%;%LOCAL_ROOT%\a2ps-4.10\bin
-SET INFOPATH=%INFOPATH%;%LOCAL_FS%/a2ps-4.10/info
-SET MANPATH=%MANPATH%;%LOCAL_ROOT%\a2ps-4.10\man
-
-rem python
-
-SET PATH=%PATH%;\Program Files\Python
-
-rem perl
-
-SET PATH=%PATH%;\qub
-
-rem yodl
-
-SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.30.0.pre10\bin
-set MANPATH=%MANPATH%;%LOCAL_ROOT%\yodl-1.30.0.pre10\man
-
-uname -sv
-bash -login
-)
-
-Please look over this carefully. Be careful with the forward and
-backward slash notations. The paths specified were done for good
-reasons. Maybe someday we will all be using code(UNC). Note the
-tt(BISON) entry and the tt(PATH) ordering in particular. Also note
-that the generic file(cygnus.bat) you will be looking at does not
-include alot of the packages listed. We will be installing some of
-these.
-
-
-The installation also suggests that you create a directory file(/bin)
-and copy file(/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe) to
-file(/bin). The file(sh.exe) shell provided by Cygnus is a descendant
-of the file(ash) shell. The file(sh.exe) shell has improved greatly
-and is much faster than the file(bash) shell for script invocations.
-So this is my recommendation for post installation steps. From a
-file(bash) shell:
-
-itemize(
-it()code(cd /)
-it()code(mkdir bin)
-it()code(cd /bin)
-it()code(cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/sh.exe sh.exe)
-it()code(cp /gnuwin32/cygwin-b20/H-i586-cygwin32/bin/bash.exe bash.exe)
-it()code(cd /)
-it()code(mkdir /tmp)
-it()code(chmod a+rwx tmp)
-it()code(mkdir /etc)
-it()code(cd /etc)
-it()code(mkpasswd -l > passwd)
-it()code(mkgroup -l > group)
-)
-
-subsubsubsect(Binary Mounts) label(binary)
-
-There is also some discussion of how you want to em(mount) the Cygnus
-development kit. em(mount) is a tt(UNIX) term that refers to the
-mechanism used to provide a disk resource to the filesystem. Cygnus
-supplies a mechinism for em(mounting) a filesystem as a tt(DOS) like
-resource or a tt(UNIX) like resource. Among other things this
-attempts to deal with the text file carriage return line feed on
-tt(DOS) versus the line feed on tt(UNIX) and the issue that tt(DOS)
-has two file types, text and binary. Where tt(UNIX) deals with a
-single streams type. My opinion on this matter currently is to use
-binary mounts only. This can be accomplished by:
-
-itemize(
-it() From a bash shell, umount /
-it() mount -b d: /
-)
-
-If you have other disks that you intend to use for data generated by
-cygnus tools you will have to mount those devices with the em(-b)
-switch.
-
-
-subsubsect(Ecgs Compiler, assembler, and linker)
-lurl(http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html)
-
-Cygnus now distributes the ecgs compiler with cygwin-b20.
-
-subsubsect(bf(GNU)'s Internationalization Package)
-lurl(http://www.gnu.org/order/ftp.html)
-
-Considering the origin of the major contributors of lilypond, this is a
-must. However before we actually do a bf(GNU) build we have to
-discuss some caveats of the Windows-NT OS in particular the naming of
-executable files. tt(Windows-NT) uses a .exe extension where tt(UNIX)
-does not use an extension. This causes a problem during the
-installation portion of a bf(GNU) build. The following script can be
-used to help alleviate this problem.
-
-verb(
-#!/bin/sh
-
-realinstall=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/install.exe
-args=''
-while [ $# -ne 0 ]
-do
- case $1 in
- -*CHAR(41) args="$args $1"
- ;;
-
- *CHAR(41) if [ -f $1.exe ]; then
- args="$args $1.exe"
- else
- args="$args $1"
- fi
- ;;
- esac
- shift
-done
-
-$realinstall $args
-)
-
-I place this in script file(~/bin). The LilyPond configure, build,
-and install process handles this with it's own install script. In
-addition there are patches to the cygnus install command that also
-deals with this problem. Having said that, here is how one
-might build the em(gettext) package.
-
-itemize(
-it() download the package from one of the ftp sites.
-it() From a bash shell, cd ~/usr/src.
-it() tar zxf gettext-0.10.tar.gz
-it() cd gettext-0.10
-it() ./configure --prefix=$CYGFS/H-i586-cygwin32
-it() make
-it() make install
-)
-
-subsubsect(bf(GNU)'s roff package)
-lurl(http://www.gnu.org/order/ftp.html)
-
-Following the instructions for em(gettext) package to download, build,
-and install the em(groff) package.
-
-subsubsect(Python Programing Language)
-lurl(http://www.python.org)
-
-Python is the scripting language of choice for a lilypond build.
-There is a native tt(Windows-NT) self extracting binary distribution
-available. I recommend installing Python in a directory that does
-bf(not) have spaces. And then place it in the bash shell path by
-editing $CYGFS/cygnus.bat.
-
-subsubsect(Perl Programing Language)
-lurl(http://www.cpan.org)
-
-I believe perl is used in some legacy scripts to date. There is a
-native tt(Windows-NT) self extracting binary distribution available.
-I recommend installing Perl in a directory that does bf(not) have
-spaces. And then place it in the bash shell path by editing
-$CYGFS/cygnus.bat.
-
-subsubsect(Yodl Document Language)
-lurl(http://www.xs4all.nl/~jantien/yodl/)
-
-Yodl for documentation in LilyPond. It is currently being updated by
-Jan Nieuwenhuizen. The development methodology of em(Yodl) as well as
-em(LilyPond) relies on a the following directory structure:
-
-label(dirstr)
-verb(
-$HOME/usr/src/
- |-releases/
- |-patches/
- |-test/
-)
-
-description(
-
-dit(releases/) Downloaded and generated releases live here. For
-example file(yodl-1.31.7.tar.gz) and file(lilypond-1.1.17.tar.gz).
-
-dit(patches/) Downloaded and generated patches live here. For
-example file(yodl-1.31.7.diff.gz) and file(lilypond-1.1.17.diff.gz).
-
-dit(test/) This directory is used to generate releases and patches.
-
-)
-
-I strongly recommend using this file structure to build em(yodl) and
-em(lilypond).
-
-itemize(
-it() download the package from
-lurl(http://www.xs4all.nl/~jantien/yodl/) to
-file($HOME/usr/src/releases).
-it() From a bash shell, cd file($HOME/usr/src).
-it() tar zxf releases/yodl-em(<version>).tar.gz
-it() cd yodl-em(<version>)
-it() ./configure --prefix=/gnuwin32/yodl-em(<version>) --srcdir=.
-Since em(yodl) is under development I choose to install it in a
-version rooted directory. This allows me to test newly released
-versions without losing a known working version.
-it() make
-it() make install
-it() place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-verb(\
-rem yodl
-
-SET PATH=%PATH%;%LOCAL_ROOT%\yodl-1.31.7\bin
-
-)
-)
-
-subsubsect(guile)
-
-GUILE, GNU's Ubiquitous Intelligent Language for Extension, is a
-library that implements the Scheme language plus various convenient
-facilities. It's designed so that you can link it into an application
-or utility to make it extensible. GNU's plan is to link this library
-into all GNU programs that call for extensibility.
-
-itemize(
-it() download guile-1.3 patch from
-lurl(http://home.austin.rr.com/jbr/jeff/lilypond/guile.patch) and save it
-to file(/tmp/guile.patch).
-it() download guile-1.3 from one of GNU's ftp sites.
-it() From a bash shell, tar zxf guile-1.3.tar.gz
-it() cd guile-1.3
-it() patch -p2 < /tmp/guile.patch
-it() LD=/gnuwin32/cygwin-b20/H-i586-cygwin32/bin/ld \ nl()
- ./configure --prefix=$CYGFS/H-i586-cygwin32
-it() make sure bin_PROGRAMS macro in libguile/Makefile does em(not) have the
-.exe extension during the build
-it() make
-it() make sure bin_PROGRAMS in libguile/Makefile em(does) have the
-.exe extension during the install. Yuck.
-it() make install
-)
-
-
-subsubsect(LilyPond) label(lilybuild)
-itemize(
-it() download the package from
-lurl(http://www.cs.uu.nl/people/hanwen/lilypond/) to
-file($HOME/usr/src/releases).
-it() From a bash shell, cd file($HOME/usr/src).
-it() tar zxf releases/lilypond-em(<version>).tar.gz
-it() cd lilypond-em(<version>)
-it() ./configure --prefix=/gnuwin32/lilypond-em(<version>) \ nl()
- --srcdir=. nl()
-Since em(lilypond) is under development I choose to install it in a
-version rooted directory. This allows me to test newly released
-versions without losing a known working version.
-it() make
-it() make install
-it() place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-verb(\
-rem lilypond
-
-SET PATH=%PATH%;%LOCAL_ROOT%\lilypond-1.1.17\bin
-
-)
-)
-
-subsect(Maintaining lilypond on Windows-NT) label(maintain)
-
-If you have built em(lilypond) on tt(Windows-NT) using the directory
-structure described link(previously)(dirstr) and the process described
-in section ref(lilybuild), then you are ready to maintain
-em(lilypond). It can not be that easy!? Well, there is one caveat.
-Currently to use the file(stepmake/bin/release.py) and
-file(stepmake/bin/package-diff.py) scripts you need to obtain/build a
-version of em(python) that was built with bf(Cygnus) development kit.
-The process I used is as follows:
-
-itemize(
-it() obtain python source from lurl(http://www.python.org)
-it() tar zxf /tmp/python-em(<version>).tar.gz
-it() cd python-em(<version>)
-it() configure --prefix=/gnuwin32/Python-em(<version>)
-it() edit toplevel file(Makefile) code(EXE) macro so it reads code(EXE=.exe)
-it() make
-it() make install
-it() place it in the bash shell path by editing $CYGFS/cygnus.bat.
-For example:
-verb(\
-rem python
-
-SET PATH=%PATH%;%LOCAL_ROOT%\python-1.5.1\bin
-
-)
-)
-
-I choose to build em(lilypond) with the standard tt(Windows-NT)
-em(python) and use the bf(Cygnus) version for using the release
-scripts. This way I can make sure the tt(Windows-NT) em(python)
-version is able to build em(lilypond). Currently there are several
-issues with the release scripts. Using code(os.link) and
-code(os.system(set -x;...)) are to name a few.
-
-To generate a new release and patch you must use the directory
-structure described link(previously)(dirstr). And follow the
-instructions found in file(PATCH.txt). Editing
-file(Documentation/AUTHORS.yo), file(VERSION), and file(NEWS) is also
-required. When my edits are complete and tested I:
-
-itemize(
-it() Edit file(config.make) and change em(python) path to the
-bf(Cygnus) version: code(PYTHON=/gnuwin32/Python-1.5.1/bin/python).
-it() make release
-)
-
-The new release is placed in file(releases) directory and the patch is
-placed in the file(patches) directory. I email the new patch to
-email(gnu-music-discuss@gnu.org). More than one patch a day can be
-generated by:
-
-itemize(
-it() cd $HOME/usr/src
-it() tar zxf releases/lilypond-em(<version>).em(<patchlevel>)
-it() use your normal configure
-it() make edits
-it() Change file(VERSION) to increment em(<patchlevel>)
-it() Change file(NEWS)
-it() make release
-)
-
-subsect(Running lilypond on Windows-NT) label(run)
-
-We are now distributing a formated binary distribution for
-Windows-NT. Please refer to
-lurl(http://home.austin.rr.com/jbr/jeff/lilypond/) for current news,
-download, installation, and running information.
-
-Jeffrey B. Reed email(daboys@austin.rr.com)
-
-
-sect(RUNNING LILYPOND -- by Dominique Cretel)
-
-You may want to refer to section ref(run), for more current
-information about downloading, installing, and running the Windows-NT
-binary distribution.
-
-enumerate(
-eit() First, I have download tha 0.1.64 version of LilyPond music software.
-
-eit() Then I extract it in a temp directory, and I move the directory
-"lilypond-0.1.64" to the root directory of my D drive.
-
-eit() I go to the D:\Lilypond-0.1.64\tex directory to modify the
-lilyponddefs.tex file (lines 75 and 84), and comment all
-cmbx15 ans cmbx14, and replace them by cmbx12.
-
-eit() build a command file like this:
-Note: I use MiKTeX to process the tex file generated.
-
-verb(
----begin ly2dvi.bat
-echo off
-set ver=0.1.64
-set path=%path%;d:\lilypond-%ver%\bin
-lilypond -I d:\lilypond-%ver%\init %1
-rem *** pause
-
-set path=c:\texmf\miktex\bin;%path%
-set TEXINPUTS=%TEXINPUTS%;d:\lilypond-%ver%\tex
-set MFINPUTS=%MFINPUTS%;d:\lilypond-%ver%\mf
-tex %1.tex
-rem *** pause
-
-dvips %1.dvi
-rem *** pause
-
-set path=%path%;d:\gstools\gsview
-gsview32 %1.ps
----end ly2dvi.bat
-)
-
-eit() execute lilypond by doing:
-verb(
-ly2ps silly <Enter>
-)
-)
-
-Note:
-nl()
-You'll better have to put the SET commands lines in a separate command
-file to avoid consumming each time environnment ressources.
-
-Bye,nl()
-Dominique Cretel email(dominique.cretel@cfwb.be)
-
-
-sect(PROBLEMS AND ANWSWERS)
-
-subsect(CONFIGURE AND INSTALL)
-This is all to confusing. I have:
-enumerate(
-eit() downloaded file(/tmp/lilypond-0.1.78.tar.gz)
-eit() verb(
- cd ~/usr/src
-)
-eit() verb(
- tar zxf /tmp/lilypond-0.1.78.tar.gz
-)
-eit() verb(
- ./configure --prefix=/users/jeff/lilypond-0.1.78 \\\
-
- --enable-tex-prefix=/users/jeff/lilypond-0.1.78/texmf \\\
-
- --enable-tex-dir=/users/jeff/lilypond-0.1.78/texmf/tex \\\
-
- --enable-mf-dir=/users/jeff/lilypond-0.1.78/texmf/mf
-)
-eit() verb(
- make
-)
-eit() verb(
- make install
-)
-)
-
-I did have a problem with lilypond.info. And I will look into this
-further. After mending lilypond.info issue, it compiled and install
-with no problems.
-
-I have 64 Meg of physical memory and 64 Meg of swap. Actually I need
-to increase the swap space. If a memory problem is occuring it most
-likely is during the link process of lilypond. There is a boat load
-of objects to link.
-
-Jan the mount -b stuff is confussing to me. I have the entire system
-mounted _without_ -b and only use -b on certain paths for programs
-that create binary files that do not use O_BINARY open option. By the
-way the midi file open is one of these cases, I need to look into
-that. I have had no problems with this methodology.
-
-
-subsect(DRIVE D:)
-
-The windows multiroot filesystem is an utterly broken concept. Please
-do everything on one (urg) drive, C:.
-
-verb(
-> configure
-> creating cache ./config.cache
-> [..]
-> creating config.make
-> creating config.hh
-> cd: lstat /d failed
-)
-
-Ok, this looks like another stupid windows problem.
-You're working on 'drive D:', right?
-
-I can think of some solutions, but i don't know if they work;
-i just had to do some work in windows some time ago. If you
-have problems with this, please ask email(gnu-win32@cygnus.com).
-I'll start with the simplest:
-itemize(
- it() do everything on drive C:, or
- it() explicitely mount drive d:, work from there:
- verb(
- mkdir -p /mnt/d
- mount d: /mnt/d
- cd /mnt/d/lilypond-x.y.z/
- )
- it() make d:/ the root of cygnus, in cmd.exe/command.exe do:
- verb(
- umount /
- mount d: /
- )
-)
-
-
-subsect(INSTALLING TOOLS)
-
-> - First I have installed Python (for win32) "Pyth151.exe" and "Configure
-nl()
-> don't find it. I had to put it in the path for configure find it?
-nl()
-
-Yes, of course. It should be possible to have different versions of tools
-installed (e.g. perl 4 and perl 5). The best way to tell people (or tools
-like configure) which one to use is to put it in the path?
-
-Another small unix lesson: Where under dos each program installs itself
-into a nice directory
-verb(
- c:\DosProgram\*
-)
-under unix, installation is handled centrally. Executables go in
-file(/usr/bin) (or file(/usr/local/bin)), and are always in your path.
-
-subsect(VIRTUAL MEMORY)
-
-verb(
-> 4. make -C lily don't work. I get an error (see below). I get several
-> object files in the ./lily/out directory (34 files: 17 *.dep, 16 *.o,
-> and 1 *.hh):
-> [...]
-> include/engraver-group.hh:35: virtual memory exhausted
-> make: *** [out/bar-grav.o] Error 1
-> bash-2.01$
-
-)
-
-Ok, so everything works now, there's only some error with one of the
-source files. Lets see which one (and now the cc's now why they're
-reading this :-)
-
-It looks like you've run out of memory. You should compile without
-optimisation, gcc/egcs need a lot of memory for optimising.
-Reconfigure without optimisation:
-verb(
- configure --disable-optimise
-)
-or edit file(config.make):
-verb(
- ## USER_CXXFLAGS = -g # -O no optimise!
- USER_CXXFLAGS = -g
-)
-
-There are some other things to look at: how much RAM do you have
-(please say something > 8Mb :-)? Although it might be an egcs bug,
-you should have a look at the size of your swap file.
-For an US version of windows, you should find it here:
-verb(
- /start/settings/control-panel/system/performance/virtual-memory
-)
-you see, amongst others, these entries:
-verb(
- paging file size for selected drive:
-
- space-available: xx
- initial-size: xx
- maximum-size: xx
-
- total paging file size for all drives
-
- currently allocated: xx
-)
-Try to set:
-verb(
- initial-size: 64
- maximum-size: 128
-)
-Make sure that:
-itemize(
-it() maximum-size >= 128 Mb
-it() urrently-allocated + space-available >= 128 Mb
-)
-
+++ /dev/null
-If you have the Cygnus gnu-windows32 port of the GNU utils, LilyPond
-will work in Windows-NT (/95/98?).
-
-We still recommend you use Unix. In particular, use GNU/Linux: We've
-been there, and we've seen it happen several times. It is em(much)
-easier and quicker to install RedHat Linux and LilyPond than to
-obtain, compile and install all the necessary tools to compile and run
-LilyPond on Windows.
-
+++ /dev/null
-
-
-So to answer your question about staff sizes:
-
-You're asking the wrong question.
-
-Since the 1850's music has bee blown up and shot down to any size you want.
-This is, for reasons I'll get into later, often a really bad mistake. This
-is also the reason why looking at scores and trying to measure their size,
-and then trying to make sense out to the result can be so frustrating.
-
-In real engraving, everything, and I do mean everything, is set up on a
-horizontal AND vertical grid. The real question is not how large is the
-staff, but how many spaces across.
-
-If you take the height of the staff and divide it into the length, and then
-multiply by 4 you will have the number of units on the staff. Different
-publishing houses have different engraving areas. The old Breitkopf
-classical piano format was 107 accross x 154 high. The modern piano format
-is about 119 accross. The vertical varies with the kind of music and the
-publisher. Because C.F. Peters has a horizontal engraving size of 7 3/8
-inches, there staff is 118 accross. G.Schirmer is 7 5/8 so they wind up with
-121. Score's default is 7.5 inches so you wind up with 119. This is what is
-usualy called a Rastral 3. Rastral 2 is about 107 or 108, Rastral 4 is about
-127 - 132.
-
-Rastral 3 translates in SCORE to a Code 8 P5 value of .72. This is very
-convienent since the staff is already locked on the grid (which means you
-can move the staff by intering only two digits, rather than four, or using
-the cursor arrows.
-
-In SCORE, the P5 value multiplied by .35 will give you the staff height in
-inches (FORTRAN'S default resolution is 4000 x 4000 dpi). Again divide the
-height into the satff width (7.5 inches for SCORE) and multiply by four for
-the staff width in units that are the same as the vertical space between two
-adjacent staff lines.
-
-Since the default spacing for P5=1 is five spaces between staves, and this
-(for reasons that I will never, ever understand) remains constant when the
-staff sizes is changed, if you want to lock onto the vertical grid you have
-to divide 18 by the P5 value and multiply by -1. For P5 = .72 this will give
-you a value of -25. If you set Code 8 P4 staff Nr. 2 to -25, staff one and
-two will print right on top of each other. If you set the P4 of staff Nr. 3
-to -50 all three staves will print on top of each other. And so on. This is
-very handy for engraving more than one voice on a line since the edit
-function (EDI) will always work. Otherwise it doesn't.
-
-Now this is getting too long. Think about it, and I'll answer your
-questions. Don't look for any of this in the manuals, it isn't there.
-
-To close up, the trouble with reducing and enlarging is that, as
-typographers figured out in the 16th century, when you change the size of a
-font, the shapes of the symbols have to change too. A nice fat serif in 72
-points will dissapear if the symbol is reduced to 7 points. SCORE's font
-isn't too bad around Rastral 5. Otherwise it needs help. If you look at good
-engraving in SCORE you will notice that different engravers have their own
-symbol libraries. A real music engraving program would have to have a least
-8 different sets of symbols. Which is a bit of work.
-
-george mcguire
-
-****
-
-
-There isn'y really anything usefull written by high quality engraving. The
-reason is simple - the whole system was based on apprenticeship, and if you
-want to sell it, you can't give it away.
-
-Also engravers don't tend to be very verbal. The one great teacher I had,
-Walter Boelke who apprenticed at Roeder and became the chief engraver at
-G.Schirmer in New York, never told me anything. But he would sit next to me
-and grunt when I did something right.
-
-
-*******
-
-
->
->My best reference (Wanske) says that Rastral are fixed sizes of
->staffs, so you are saying that the staff lengths come in fixed sets as
->well.
->
-
-The sizes were fixed for the publisher she was working for (Schott), which
-are very close to Breitkopf.
-But the Roeder sizes were different. There is a long history behind this -
-starting with the fact that the first German engraving workshop (methods,
-machinery, tools and engravers) was imported from England (?).
-
-
-******
-
->If I understand you correctly, you are saying that the scaleable part
->of msuic isn't so much the height, but how many symbols you can cramp
->onto one line, and how many lines (systems) on one page. Or do you
->mean that I should not be thinking in "dimensions" but "ratios".
->
-
-Yes, basically the rations are what is important. The horizontal size was
-dependent on the piece of metal.
-On the other hand metal was expensive and the sizes and layout had
-everything to do with how much you could cram on a page.
-
-****
-
-That's okay as far as it goes. But if you look at different size noteheads
-you will notice that they are ovals, and that the angles from the horizontal
-of the main axises change with the size. Of course this is something Tex
-deals with easily and well.
-
-****
-
-Table from Wanske:
-
-
-16.5 15.5 14.5 13.5 12 11.5 9
-143 12 11 10 9 8.5 7
-11 10 9 8 7 6.5 5
-
-
+++ /dev/null
-article(FAQ - GNU LilyPond FAQs)()()()
-
-DEFINEMACRO(question)(1)(subsect(ARG1))
-
-sect(Miscellaneous)
-
-question(HELP! I'm stuck!)
-
-Please read this document carefully. If you are still at loss,
-send your questions to the bf(mailing list), and not to authors
-directly.
-
-Note: relative paths are meant to be relative to the source directory
-
-sect(Installing)
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(If I install the .exe file on my DOS/windows 3.11 machine, it doesn't work)
-
-The DOS port is done with the cygnus gnu/windows32 port of the GNU utils.
-It does em(not) work with windows 3.x; you need Windows-NT (95/98?). This
-is not a recommendation, however. We recommend you use Unix, in
-particular, use GNU/Linux. For further information see file(README-W32).
-
-question(Where is guile-config)
-
-RedHat RPMS don't include guile-config. You need guile-config as it
-was produced during the RPM build run. Build the RPM from source
-(file(.src.rpm)), and use the guile-config that is in
-file(/usr/src/redhat/BUILD/guile-1.3/guile-config/).
-
-
-question(I get all kinds of errors while compiling file(parser.cc))
-
-LilyPond uses features of bison version 1.25. Please confirm that
-you are using a version 1.25 or better, that is bf(GNU) bison
-bf(1.25). Don't forget to do "make clean" after installing it. Don't
-forget to remove the stale file(bison.simple) as well.
-
-If the problem persists, then please send a bug report to the mailing list.
-
-question(I upgraded by applying a patch, and now my configure/build breaks.)
-
-Patches don't include automatically generated files, i.e.
-file(configure) and files generated by file(configure). Regenerate them
-yourself:
-verb(
- autoconf
- configure
-)
-You might need to create some extra "out" directories. Do this with
-verb(
- make outdirs
-)
-question(Some of your neat scripts fail, what directories do you use:)
-
-[This only applies if you don't do code(make install), and develop out
-of the source directory]
-
-I have a directory which contains all our development projects
-verb(
- ~/usr/
-)
-
-which looks like file(/usr/)
-verb(
- bin/
- share
- lib/
- share/
- src/
-
- etc....
-)
-
-The directory file(~/usr/src/) contains something like
-includefile(../stepmake/Documentation/layout.yo)
-)
-
-~/usr/src/bin is in the PATH, and contains symbolic links to the
-compiled executables.
-
-question(Is there an emacs mode?)
-
-Yes. It is included with the source archive as mudela-mode.el. If
-you have an rpm it is in /usr/doc/lilypond-X/. You have to install it
-yourself.
-
-question(How do i create the file(.tfm) files?)
-
-You don't. The file(.tfm) files should be generated automatically by
-Metafont when you run TeX(). Check your TeX() installation, or ask
-your local TeX() guru. The supplied file(.afm) files are intended to
-be used by LilyPond, not by any other programs.
-
-
-sect(Documentation)
-
-question(Why is the documentation/website/etc. so lousy?)
-
-LilyPond development is moving quite fast, documentation will often
-lag a bit behind. We must always make a choice between writing more
-doco, writing more code and answering email.
-
-If you think you can make a correction, or devised a solution that
-should be documented, please do so and send in a patch.
-
-sect(Language: mudela)
-
-question(Why can't you type code(#c) in stead of code(cis) ?)
-
-We think that code(#c) looks as if you are entering the symbols to
-print (which you are not; remember, you're entering the musical
-content in Mudela)
-
-
-question(Why do I have to type the accidentals to the note if I specified them?)
-
-Take this example
-verb(
- cis cis
-)
-Independently of how it was written and what the current key was, you
-would say that you are playing and reading "two C-sharp" notes. We
-have tried to make the language somewhat context-free. Of course
-sheet music is not context-free. Unfortunately, sheet music is also 2
-dimensional, and ASCII is not.
-
-Technically it would be feasible to have the Interpreting phase do
-tricky things to add (or leave out) the accidentals, but we think that
-it is impractical: it hampers the readability and portability of your
-source, since you need LilyPond to fill in the details and actually
-make sense of it.
-
-
-question(What is code(cis) anyway)
-
-code(cis) is the dutch naming for C-sharp. The notes are named
-a, b,.., g. The suffix -is means sharp, and -es flat. This system is
-common in a number of languages (such as swedish, dutch, german.)
-Certain other languages (such as English, French and Italian) just add
-the word for "sharp" to the notename.
-
-We chose the Dutch system, because we're dutch. You are free to chose
-whatever names you like; they are user definable.
-
-
-question(Why are [] around the notes, and () inbetween?)
-
-[] designate beams, a note can only be in one beam at the same
-time. () is a slur, which connects notes. You need to be able to
-specify
-verb(
- a()a()a
-)
-
-question(I want to insert some TeX commands.)
-
-You shouldn't: it's against LilyPond philosophy to have typesetting
-commands in the mudela source. Moreover, this would be difficult.
-LilyPond uses TeX like a glorified output engine: the output consists
-of (x,y) positions and symbols. You can only sensibly do TeX stuff in
-the symbol string. You can access the symbol string easily for some
-symbols (notably lyrics and code(^"text") commands).
-
-
-sect(Do you support ...)
-
-question(Do you support pop songs (chords, single staff, lyrics)?)
-
-Yes, see the file(twinkle-pop) example.
-
-
-question(Do you support guitar chord diagrams?)
-
-No. Go ahead and send a patch.
-
-We ourselves don't play guitar, and don't know the fine points of this
-notation. We would welcome anyone who could give this a try.
-
-question(Do you support TAB notation?)
-
-No. The same as for the previous question goes, but TAB is a lot
-more work than diagrams (TAB needs modification of Parser, Lexer,
-Staff, Notehead, Stem code and all the code that creates these graphic
-elements.)
-
-question(Do you support multiple staff-sizes?)
-
-Yes. At this time you can choose between 11, 13, 16, 19, 20, 23 and
-20 pt staff-size. Use the staffLineLeading property for setting the
-size of the staff, and fontSize for setting the size of the glyphs.
-
-question(Do you support Gregorian chant notation?)
-
-No. Go ahead.
-
-question(Do you support grace notes?)
-
-Yes. See file(input/test/grace.ly)
-
-
-sect(How do I ....)
-
-question(How do I change the TeX layout?)
-
-See file(lilyponddefs.tex), it has some comments. Or use file(ly2dvi).
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(How do I place lyrics under em(each) of the staves in a score, as choral music. I can work out how to put lyrics for each line all under the top line, or at the bottom but not between!)
-
-You change the order lyrics and staves. You have to name all
-staves (lyric and melodic), otherwise they will end up in the same
-staff/lyricline
-verb(
- \score {
- < \melodic \type Staff = "treble" \trebleMelody
- \lyric \type Lyrics = "tlyrics" \trebtext
- \type Staff = "bass" \melodic \bassMelody
- \lyric \type Lyrics = "blyrics" \basstext
- >
- \paper { }
- }
-)
-
-question(How do I put more than one marking on a note.)
-
-You can stack them
-verb(
- c4^"a"^"b"
-)
-or use spacing-notes to put markings at different horizontal positions
-verb(
- < c1
- { s4\ff s4^"text" s4-\marcato s4 }
- >
-)
-This also works for crescendi, eg,
-verb(
- < c1
- { s4\< s2 \! s4 }
- >
-)
-
-question(How do I combine multiple pieces into one document)
-
-There are several solutions:
-
-itemize(
-it()
-verb(
- ly2dvi foo.ly bar.ly
-)
-produces one combined file(foo.dvi)
-it() make a toplevel file(.ly) file that contains al pieces:
-verb(
- % booklet.ly
- \input "piece-1.ly"
- \input "piece-2.ly"
- \input "piece-3.ly"
-)
-it() make a hybrid TeX()/LilyPond file(.doc) document (see the
- file(Documentation/tex) directory).
-)
-
-For the first two solutions, you will need to move code(\header) info
-in each individual piece from toplevel into the code(\paper) block.
-
-There are several examples in the file(mutopia) directory.
-
-
-question(How do I get bar numbers?)
-
-See file(input/test/bar-scripts.ly).
-
-
-question(How do I change the tagline 'Lily was here')
-
-In the code(\header) field, add a code(tagline) entry, eg
-verb(
-tagline="Typeset by GNU LilyPond"
-)
-
-to get a bit less frivolous tagging.
-
-sect(Development)
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(Could you implement feature XXXX? It is really easy, just extend the syntax to allow YYYY!)
-
-If it is reasonable, I'll add XXXX to the TODO list. In general
-finding a cute syntax (such as YYYY) isn't very hard. The complicated
-issue how to adapt the internals to do XXXX. The parser is really a
-simple front end to the complicated internals.
-
-question(Can I join in on LilyPond development? How do I do this?)
-
-LilyPond development is open for anyone who wants to join. We try
-to use a Bazaar style development model for LilyPond, see
-lurl(http://locke.ccil.org/~esr/writings/cathedral.html.) This means:
-frequent releases, everyone can send in a patch or do suggestions and
-all development discussions are public.
-
-To be precise, discussions take place on the gnu-music-discuss mailing
-list, which is open for subscription to everyone.
-
-
-question(I want to implement XXXX! Should I do this?)
-
-There might be better ways of doing XXXX, so it's a good thing to
-ask about this before you start hacking. If you want to keep in touch
-with current developments, you should subscribe to the mailing list
-(see the "links" section of the documentation).
-
-
-question(Is there a GUI frontend? Should I start building one?)
-
-LilyPond currently has no graphical interface. The authors seriously
-doubt if a simple-minded approach (dragging and dropping notes) is any
-easier or quicker to use than mudela. But for composing a graphical
-environment probably is indispensable.
-
-In any case email(Derek Wyatt)(wyatt@scar.utoronto.edu) is working on
-GTK based editor, but that effort practically died. (see
-lurl(http://harmonia.scar.utoronto.ca).
-
-Matthew Hiller is working on extending Midiscore and Koobase to handle
-mudela. Check out lurl(http://zoo.cs.yale.edu/~meh25/).
-
-There is also a GUI package RoseGarden that could be extended to
-output mudela.
-
-If you want to work on this, please send e-mail to the mailing list
-email(gnu-music-discuss@gnu.org).
-
-
-
-question(I want to implement XXXX! How should I do this?)
-
-Your best bet of getting us to include code, is to present it as a
-"fait accompli", i.e., to send a patch to the mailing list.
-
-
-question(I made some code, how do I get you to include it?)
-
-Send in a patch:
-verb(
- diff -urN old-file new-file > patch
-)
-or
-verb(
- diff -urN old-directory/ new-directory/ > patch
-)
-Alternatively, you can use issue the command
-verb(
- make diff
-)
-
-Don't forget to put your name and e-mail address
-in the file(AUTHORS.pod) file, or you won't get credits :-]
-
-
-em(Please) always send a bf(-u) diff, even if it is larger than the
-whole file.
-
-question(How do I learn the C++ code?)
-
-The entry point is in code(main()). Good luck. :-)
-
-Seriously, read, reread and reread internals and CodingStyle, and
-just start anywhere.
-
-Anywhere? Well, most of the comment doco are in the header files, so
-your best bet would be code(less lily/include/*.hh).
-
-You should also have a look using Javadoc like tools. Try
-DOC++, lurl(http://www.imaginator.com/doc++)
-
-
-question(Why GPL?)
-
-No comment.
-
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(Your make system does not adhere to GNU coding standards, could you please fix it?)
-
-No. We have evaluated the standard GNU combination for compiling
-programs (autoconf, automake, libtool) and found to be inadequate in
-several respects. More detailed argumentation is included with
-LilyPond's generic make package code(StepMake)
-(see file(stepmake-x.x.x/Documentation/automake.urgh))
-
-LilyPond already compiles into a different directory ((the different
-directory is called out/, there is one in every source directory).
-make distclean essentially reduces to file(rm -f out/*) in every directory
-
-question(gdb crashes when I debug!)
-
-Upgrade to 4.17.
-
-question(Why do I need g++ >= 2.8 / EGCS-1.1 ?)
-
-Supporting more compilers than EGCS/G++ 2.8 is unlikely to make
-LilyPond run on more platforms. It would give us an enormous headache
-in detecting and catering for every variant of every compiler: not
-having to support other compilers saves us a em(lot) of trouble.
-
-
-sect(Running)
-
-
-question(I use dvilj4, and there are lots of warning messages for the printing)
-
-You should use dvips and ghostscript to print the code(dvi) output:
-the slurs and beams are PS code(\special) commands.
-
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(My symbols are all messed up after I upgraded, I get the wrong symbols and dvi-checksum errors!)
-
-We obviously mucked with the fonts in the upgrade. Remove em(all)
-previous fonts, including the file(.pk) and file(.tfm) fonts in
-file(/var/lib/texmf). A script automating this has been included, see
-file(buildscripts/clean-fonts.sh).
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(all the pk and tfm fonts are created in the directory where the mudela file is, not in "/var/spool/texmf" where I think they should be.)
-
-Mats Bengtsson <mats.bengtsson@s3.kth.se> writes:
-
-The simple solution used by Anthony Fok in the Debian distribution of
-Lilypond is to link the mf/ directory to
-/usr/lib/texmf/fonts/source/public/lilypond Depending on what
-distribution of teTeX and Linux you have installed, there might also
-be other places like /usr/local/lib/texmf/fonts/source/public/lilypond
-or /var/spool/texmf//fonts/source/public/lilypond
-
-Wherever you put it, don't forget to run mktexlsr (or texhash for
-older installations) afterwards, so that TeX will find the files.
-Also, don't forget to remove all old .tfm and .*pk files when the font
-is updated (as it will be in version 1.1.40, for example).
-
-question(Are there scalable versions of the font?)
-
-Yes, they are type-3 fonts. In the file(mf/)
-subdirectory, issue:
-verb(
- make pfa
-) in the mf/ subdirectory. This will also make file(mfplain) for metapost.
-The file(pfa)s will be in the subdirectory file(out/).
-
-question(How does PS output work?)
-
-itemize(
- it()
-Generate the PostScript Type-3 fonts.
-it()
-Run lilypond with option tt(-f ps):
-verb(
- lilypond -fps foo.ly
-)
-it() To view the file(.ps) output with GhostView, set GS_FONTPATH to the
-directory containing the file(pfa)s. In the source tree, this is file(mf/out/).
-
-
-i.e. do something like:
-verb(
- export GS_FONTPATH=$HOME/usr/src/lilypond/mf/out
- gv foo.ps &
-)
-)
-
-Direct PS output is still experimental. For creating nice looking ps
-output, use TeX() and code(dvips).
-
-
-question(The beams and slurs are gone if use the XDvi magnifying glass!?)
-
-The beams and slurs are done in PostScript. XDvi doesn't show
-PostScript in the magnifying glass. Complain to the XDvi maintainers.
-
-
-question(I don't get midi-output, even if I use bf(-M)!)
-
-Your \score should include a \midi block, eg.
-verb(
- \score {
- \melodic { c4 c g g }
- \paper {}
- \midi {
- output = "myfile.midi";
- \tempo 4=70;
- }
- }
-)
-The bf(-M) option was added to LilyPond because processing the \paper
-block is so slow.
-
-COMMENT(look out: can't have line breaks in subsect() macro)
-question(A lot of musical stuff doesn't make it to the MIDI file, eg. dynamics, articulation, etc.)
-
-The MIDI output was originally put in as a proof that MIDI could be
-done, and as a method of proof"reading" the input. The MIDI support
-is by no means finished. Patches appreciated.
-
-
-sect(Copyright)
-
-
-question(What is Urtext? Critical Edition?)
-
-Werner Lemberg:
-
-It may be translated best as `that what the composer intended to tell
-the reader'
-
-
-Peter Chubb <peterc@aurema.com> writes:
-
-An Urtext is a reconstruction of the earliest form of a text,
-including mistakes the original author wrote. Where there is no
-available facsimile of the original, creating this can involve some
-inspired detective work (in comparing various later editions and
-trying to deduce what the original form was). As far as copyright
-goes, my guess is that, for works that are otherwise out of copyright,
-an Urtext is copyright to the person who reconstructed it, as a
-derived work from the editions s/he consulted. If the edition is
-created directly from a facsimile, as would be the case for most
-Urtext editions of music, then the amount of new (copyright) material
-is minimal.
-
-A critical edition is an edition that is designed for critical
-study of a text. It'll usually have lots of footnotes, alternative
-readings, possible realisations of bass parts and harmonies, etc. It
-aims to elucidate the author's original intentions, as opposed to
-reproduce exactly what was written. The critical apparatus will be
-copyright to its author.
-
-A playing edition is one that has been edited for modern usage.
-It'll have fewer or no alternative readings, it'll be in modern
-notation, it may have additional editorial marks (phrase marks, slurs,
-etc.) will often have a fully realised basso continuo part (if oone
-was present in the original) and may have had key changes, time
-signature changes, time compression (original in 4/1, playing edition
-in 4/4, for example, with all semibreves replaced with crotchets)
-Copyright is in the arranger/editor.
-
-
-question(How does copyright for sheet music work? Can I enter and spread my newly bought Bach urtext?)
-
-Silas S. Brown <ssb22@hermes.cam.ac.uk>:
-
-There are several aspects to sheet music copyright:
-
-1. The music itself - copyright for the composer's life plus 70 years (so
-not applicable to Bach).
-
-2. If the music is an arrangement, then the arranger holds copyright on
-that arrangement. However, you can produce your own arrangement using
-that arrangement as a reference point. Obviously your arrangement must be
-sufficently different to be called your own arrangement - you need to do
-more than change one note!
-
-3. In some countries, the same applies for editions. This could be
-relevant to the Bach example. If a modern person has edited the music,
-then they hold the copyright on the edition. This does not stop you from
-removing the editorial features - remove all editorial slurs, phrasemarks,
-ornaments etc and only leave those that you know to be original. You can
-then add some of your own if you want to be your own editor.
-
-4. If there are lyrics, then the lyricist also holds copyright. This
-does not stop you from using the music without the lyrics if it is
-otherwise out of copyright.
-
-5. The copyright of the printed page is held by the publisher for 30
-years after printing (25 in some countries). This stops you from
-photocopying (unless it's "fair use" eg. you're partially sighted and need
-to enlarge the music) or otherwise reproducing the typesetting that is
-used on it. But the copyright is only held over the typesetting work, not
-the music itself. Since Mudela specifies the notes, independently of any
-typesetting work that went into your reference copy, you are not
-duplicating any of the publisher's work.
-
-6. If you want to violate copyright, there are two main cases where you
-may do so: fair use, and with permission. The former is rather fuzzily
-defined, but it includes such things as including small extracts of a
-score in a critique, and making a large print or Braille copy for a blind
-or partially-sighted performer (many people argue that in this case it
-should always be kept with the original copy and/or destroyed after it is
-no longer needed). The latter is obvious: You can always write to the
-composer, arranger, editor, lyricist or publisher in question and ask if
-you can do whatever it is you're trying to do. Some will respond more
-readily than others, but anything that they say will override any copying
-restrictions imposed on you.
-
-
-References - best one I know is the UK-based Performing Right Society,
-lurl(http://www.prs.co.uk/) (especially "membership") and their links to other
-international equivalents.
-
-
-
-Juergen Reuter <reuterj@ira.uka.de>:
-
-[More information can be had at: ]
-
-lurl(http://lcweb.loc.gov/copyright/)
-(USA copyright law)
-
-lurl(http://fairuse.stanford.edu/)
-(meta site about copyright with many links to other resources)
-
-lurl(http://host.mpa.org/crc.html)
-(copyright from the viewpoint of the USA music publishers' association)
-
-lurl(http://www.wipo.int)
-(World Intellectual Property Organization (a UNO agency); with
-information about international copyright)
-
-
-John Sankey:
-
-See lurl(http://www.geocities.com/Vienna/Studio/1714/harpsichord.html)
-for a summary of copyright relative to old music, also for the
-expert forum for such questions.
-
-Werner Lemberg <sx0005@sx2.HRZ.Uni-Dortmund.DE>:
-
-This is not correct. Urtext editions per se are em(not) copyrighted
--- if you print exactly what the composer has written, how can there
-some copyright be added? Copyrighted are usually only the `Critical
-notes', the foreword, and the cadenzas some editors have added.
-
-This means that the `Photocopying forbidden' sign in many scores is
-not always correct for e.g. J.S. Bach -- you are allowed to copy the
-pages which don't contain editorial stuff which is probably
-copyrighted.
-
-A very unfortunate situation for the publishers.
-
-
-
-
-sect(Windows32)
-
-question(I downloaded the windows32 port, and it doesn't match the website!)
-
-The website is usually made from the latest snapshots. Binary releases,
-in particular the windows32 binaries, are only made every once in a while.
-They may lag several versions behind the latest version.
-
-question(But i want a native DOS/Windows-NT/95 port)
-
-Reconsider. Try Linux. It's fun!
+++ /dev/null
-article(GNU Music project - manifesto)(Han-Wen Nienhuys and Jan Nieuwenhuizen)()
-
-sect(Goal)
-
-
-
-The public deserves free tools for composing and printing.
-
-
-sect(Requirements)
-
-Emacs and TeX() serve as useful examples of what programs by the GMP
-should be.
-
-description(
-dit(high-quality)
- The software should be of high-quality from the application view.
-For example, the notation should be high-quality from an engraving
-point of view, like TeX()
-
-dit(high-quality) The software should be of high-quality point of
- view, like all GNU software, it should have no limits, be fast,
- etc.
-
-dit(tweakable)
- Printed music has a lot of styles, and special symbols. It may be
- unfeasible to provide and maintain lots of code that is hardwired
- into the system. The tools should be extensible/programmable like
- Emacs and TeX.
-
-dit(easy to use.)
- That is, for technical users (that can read a manual). The learning
- curve should be as flat as possible but not at the expense of comfort
- of use and power.
-)
-
-sect(Components)
-
-description(
-dit(A set of music fonts)
- In development, the Feta font.
-dit(A typesetting engine)
- In development, included in LilyPond.
- A system with rules on how to set properties of items to be printed
- (up/down directions, breaking, dimensions, etc)
- It should be suited to interactive typesetting (so, incremental
- algorithms are needed)
-dit(A display engine)
- which can display clear notewriting in (say) an X-window
- Ideally the system should cooperate with the typesetting engine
-dit(An ASCII language)
- In development, LilyPond has a language.
- Having an ASCII format which enables urtext, and easy sharing (via
- mail and news forums) encourages cooperation and exchange of music.
-dit(A printing engine)
- In development, included in LilyPond.
-dit(An input system)
- The natural way to enter composed music is singing or playing it. The
- GMP should have module which can take keyboard input or microphone
- input and convert it to computer data. (microphone input would be
- difficult)
-dit(sequencing)
- (have no clue about this)
-dit(A scanning system)
- Having a system which can produce mudela from printed scores, greatly
- simplifies creating a collection of music
-dit(A music-understanding system)
- (difficult) A system to generate accompaniments, figured bass,
- automatic accompaniment, etc.
-dit(A performing system)
- A system which can play credible performances of abstract music
- representations. LilyPond has a bare bones system, but it cannot
- (yet) be described as "credible".
-)
-
-sect(Programs)
-
-itemize(
-it()A noninteractive typesetter, suited for batch jobs, and typesetting
- existing music. This would couple the ASCII language, the printing
- engine and the typesetting engine
- LilyPond is currently representing this section.
-it()A GUI for composing. This would combine the display engine, the input
- system and the typesetting engine.
-it()Libraries for reading and writing various audio/music/notation
- formats.
-)
-
+++ /dev/null
-DEFINEMACRO(depth)(0)(.)
-DEFINEMACRO(pic)(1)(url(ARG1)(DOEXPAND(docdir)/pictures/DOEXPAND(outdir)/ARG1.png
-))
-
-DEFINEMACRO(beginbold)(0)(whenhtml(htmlcommand(<font size=4><strong>)))
-DEFINEMACRO(endbold)(0)(whenhtml(htmlcommand(</strong></font>)))
-redef(htmlnewfile)(0)()
-setchapterstring()
-
-nchapter(LilyPond: The Music Typesetter)
-
-LilyPond is a compiler that transforms an ASCII definition of music
-into beautifully engraved sheet music. A small example is included
-here:
-
-center(mudela(fragment, verbatim)(
- \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 }
-))
-
-
-Features include
-itemize(
-it() A concise yet easy-to-read input language.
-it() Beautiful output, comes with its own font.
-it() Easy interfacing with (La)TeX
-it() Support for Lyrics and Chords
-it() MIDI output
-it() Multiple voices on a staff, multiple staffs, polymetric music, nested tuplets, cross staff beaming and slurring.
-)
-
-Development releases can be had at lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development/). For more information, consult the LilyPond webpage, lurl(http://www.lilypond.org).
-
+++ /dev/null
-DEFINEMACRO(tops)(0)(../topdocs/DOEXPAND(outdir))
-DEFINEMACRO(pics)(0)(../pictures/DOEXPAND(outdir))
-
-nsect(NAME)
-
-The Documentation of LilyPond -- the GNU Project music typesetter
-
-nsect(DESCRIPTION)
-
-Note: These pages are created from the latest bf(development snapshots)
-of LilyPond. You can look at the bottom if you want to know which
-version this was.
-
-
-nsubsect(Documentation: Introduction)
-
-itemize(
-it()url(DEDICATION)(DEDICATION.html)
-it()url(FAQs)(faq.html)
-it()url(The README)(DOEXPAND(tops)/README.html)
-it()url(The installation instructions)(DOEXPAND(tops)/INSTALL.html)
-)
-
-nsubsect(Why: Background Information)
-
-itemize(
-it() url(Why?)(AIMS.html)
-it()url(The lilypond
- logo (Big, format: .png))(DOEXPAND(pics)/lelieblond.png)
-it()url(The lilypond
- logo (medium size, format: .png))(DOEXPAND(pics)/lelie_logo.png)
-)
-
-nsubsect(Documentation: manuals)
-
-
-itemize(
-it()url(User documentation)(../tex/DOEXPAND(outdir)/index.html)
-it()url(Hacker documentation)(../metadoc/DOEXPAND(outdir)/index.html)
-it()url(Manual pages)(../man/DOEXPAND(outdir)/index.html)
-it()url(Bibliography)(../bibliography/DOEXPAND(outdir)/)
-it()url(Musical vocabulary)(../tex/DOEXPAND(outdir)/glossary.html)
-)
-
-nsubsect(The program)
-
-itemize(
-it()url(The TODO list)(TODO.html)
-it()url(The Change log)(NEWS.html)
-it()url(About internal structures)(internals.html)
-it()url(The coding standards of the lilypond project)(CodingStyle.html)
-it()url(The Authors)(DOEXPAND(tops)/AUTHORS.html)
-it()url(Sending and applying Patches)(DOEXPAND(tops)/PATCHES.html)
-)
-
-nsubsect(Mail)
-
-includefile(mail.yo)
-
-nsubsect(Links)
-
-itemize(
-it()url(Papers, books and online-resources on music typesetting)
-(../tex/DOEXPAND(outdir)/index.html)
-it()url(Other packages for printing music)(../tex/DOEXPAND(outdir)/index.html)
-it()url(bf(download) LilyPond and other interesting links)(links.html)
-)
+++ /dev/null
-article(LilyPond internals)(Han-Wen Nienhuys)()
-
-This documents some aspects of the internals of GNU LilyPond. Some of
-this stuff comes from e-mail I wrote, some from e-mail others wrote,
-some are large comments taken away from the headers. This page may be
-a little incoherent. Unfortunately, it is also quite outdated. A
-more thorough and understandable document is in the works.
-
-You should use code(doc++) to take a peek at the sources.
-
-
-sect(OVERVIEW)
-
-GNU LilyPond is a "multi-pass" system. The different passes have been
-created so that they do not depend on each other. In a later stage
-some parts may be moved into libraries, or seperate programs, or they
-might be integrated in larger systems.
-
-description(
-
-dit(Parsing:)
-
-No difficult algorithms. The .ly file is read, and converted to a list
-of code(Scores), which each contain code(Music) and paper/midi-definitions.
-
-dit(Interpreting music)
-
-The music is walked through in time-order. The iterators which do the
-walking report Music to Translators which use this information to
-create elements, either MIDI or "visual" elements. The translators
-form a hierarchy; the ones for paper output are Engravers, for MIDI
-Performers.
-
-The translators swallow Music (mostly atomic gobs called Requests),
-create elements, broadcast them to other translators on higher or same
-level in the hierarchy:
-
-The stem of a voice A is broadcast to the staff which contains A, but
-not to the stems, beams and noteheads of a different voice (say B) or
-a different staff. The stem and noteheads of A are coupled, because
-the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
-these.
-
-The engraver which agrees to handle a request decides whether to to
-honor the request, ignore it, or merge it with other requests. Merging
-of requests is preferably done with other requests done by members of
-the same voicegroups (beams, brackets, stems). In this way you can put
-the voices of 2 instruments in a conductor's score so they make chords
-(the Beam requests of both instruments will be merged).
-
-dit(Prebreaking)
-
-Breakable stuff (eg. clefs and bars) are copied into pre and
-postbreaks.
-
-dit(Preprocessing)
-
-Some dependencies are resolved, such as the direction of stems, beams,
-and "horizontal" placement issues (the order of clefs, keys etc,
-placement of chords in multi-voice music),
-
-dit(Break calculation:)
-
-The lines and horizontal positions of the columns are determined.
-
-dit(Breaking)
-
-Through some magical interactions with Line_of_score and Super_elem
-(check out the source) the "lines" are produced.
-
-All other spanners can figure across which lines they are spread. If
-applicable, they break themselves into pieces. After this, each piece
-(or, if there are no pieces, the original spanner itself) throws out
-any dependencies which are in the wrong line.
-
-dit(Postprocesing:)
-
-Some items and all spanners need computation after the Paper_column
-positions are determined. Examples: slurs, vertical positions of
-staffs.
-
-dit(Output paper)
-
-)
-
-sect(mudela)
-
-Most information is stored in the form of a request. In music
-typesetting, the user might want to cram a lot more symbols on the
-paper than actually fits. To reflect this idea (the user asks more
-than we can do), the container for this data is called Request.
-
-In a lot of other formats this would be called an 'Event'
-
-description(
-dit(code(Barcheck_req))
- Checks during music processing if start of this voice element
- coincides with the start of a measure. Handy to check if you left out
- some voice elts.
-dit(code(Note_req))
- LilyPond has to decide if the ball should be hanging left or
- right. This influences the horizontal dimensions of a column, and this
- is why request processing should be done before horizontal spacing.
- Other voices' frivolities may cause the need for accidentals, so this
- is also for the to decide. The engraver can decide on positioning based on
- ottava commands and the appropriate clef.
-dit(code(Rest_req))
- Typeset a rest.
-dit(code(Span_req))
- This type of request typically results in the creation of a code(Spanner)
-dit(code(Beam_req))
- Start/stop a beam.
- Engraver has to combine this request with the stem_request, since the
- number of flags that a stem wants to carry will determine the
- number of beams.
-dit(code(Dynamic))
- Each dynamic is bound to one note (a crescendo spanning multiple
- notes is thought to be made of two "dynamics": a start and a stop).
- Dynamic changes can occur in a smaller time than the length of its
- note, therefore fore each code(Dynamic) request carries a time, measured
- from the start of its note.
-)
-
-sect(Request_engraver)
-
-In the previous section the idea of Request has been explained, but
-this only solves one half of the problem. The other half is deciding
-which requests should be honored, which should merged with other
-requests, and which should be ignored. Consider this input
-
-verb(
- \type Staff < % chord
- { \meter 2/4; [c8 c8] }
- {\meter 2/4; [e8 e8] }
- >
-)
-
-Both the cs and es are part of a staff (they are in the same
-Voice_group), so they should share meters, but the two [ ] pairs
-should be merged.
-
-The judge in this "allocation" problem a set of brokers: the requests
-are transmitted to so-called engravers which respond if they want to
-accept a request eg, the code(Notehead_engraver) will accept
-code(Note_req)s, and turn down code(Slur_req)s. If the Music_iterator
-cannot find a engraver that wants the request, it is junked (with a
-warning message).
-
-After all requests have been either assigned, or junked, the Engraver
-will process the requests (which usually means creating an code(Item)
-or code(Spanner)). If a code(Request_engraver) creates something, it
-tells the enclosing context. If all items/spanners have been created,
-then each Engraver is notified of any created Score_element, via a
-broadcasting system.
-
-nsubsect(example:)
-
-verb(
- c4
-)
-
-produces:
-
-verb(
- Note_request (duration 1/4)
- Stem_request (duration 1/4)
-)
-
-Note_request will be taken by a code(Notehead_engraver), stem_request
-will be taken by a code(Stem_beam_engraver). code(Notehead_engraver)
-creates a code(Notehead), code(Stem_beam_engraver) creates a
-code(Stem). Both announce this to the Staff_engraver. Staff_engraver
-will tell code(Stem_beam_engraver) about the code(Notehead), which
-will add the code(Notehead) to the code(Stem) it just created.
-
-To decide on merging, several engravers have been grouped. Please
-check file(init/engraver.ly).
-
-
-sect(ITEMS and SPANNERS)
-
-The symbols that are printed, are generated by items and spanners
-(staff-elements). An item has one horizontal position, whereas a
-spanner spans several columns.
-
-sect(DEPENDENCIES)
-
-In music symbols depend on each other: the stems of a beam should
-point in the same direction as the beam itself, so the stems of a beam
-depend on the beam. In the same way do scripts depend on the direction
-of the stem. To reflect this, LilyPond has the notion of dependency.
-It works in the same fashion that code(make) uses to build programs:
-before a stem is calculated, its dependencies (the beam) should be
-calculated. Before a slur is calculated, its dependencies (stems,
-noteheads) should be calculated.
-
-sect(BREAKING)
-
-So what is this PREBREAK and POSTBREAK stuff?
-
-Let's take text as an example. In German some compound
-words change their spelling if they are broken: "backen" becomes
-"bak-ken". TeX has a mechanism to deal with this, you would define
-the spelling of "backen" in TeX in this way
-
- \discretionary{bak-}{ken}{backen}
-
-These 3 arguments are called "prebreak", "postbreak" and "nobreak"
-text.
-
-The same problem exists when typesetting music. If a line of music is
-broken, the next line usually gets a clef. So in TeX terms, the clef
-is a postbreak. The same thing happens with meter signs: Normally the
-meter follows the bar. If a line is broken at that bar, the bar along
-with the meter stays on the "last" line, but the next line also gets a
-meter sign after the clef. Using the previous notation,
-
- \discretionary{bar meter}{clef meter}{ bar meter }
-
-In GNU Lilypond, we have the same concepts (and the same
-terminology). Each (nonrhythmic) symbol is typeset in a nonrhythmic column
-At a breakpoint, multiple symbols are printed; symbols to be printed
-if the line is not broken, symbols to appear on the previous line, and
-on the next line if it is broken.
-
-sect(SPACING)
-
-
-Some terminology: I call a vertical group of symbols (notes) which
-start at the same time a "column". Each line of a score has notes in
-it, grouped in columns. The difference in starting time between those
-columns makes it possible to determine ideal distances between those
-columns.
-
-Example:
-
-verb(
- time ----->
-
- cols: col1 col2 col3 col4
-
-
- voice1 1 1
-
- voice2 2 2 2 2
-
-
- (1 is a whole note, 2 a half note.)
-
- time_difference (col1 , col2) = 0.5 wholes,
- time_difference (col1 , col3) = 1 wholes,
- time_difference (col2 , col3) = 0.5 wholes,
- etc.
-)
-
-these differences are translated into ideal distances
-
-verb(
- distance (col1,col2) = 10 pt
- distance (col1,col3) = 14.1 pt
- distance (col2,col3) = 10 pt
- etc.
-)
-
-as you can see, these distance are conflicting. So instead of
-satisfying all those ideals simultaneously, a compromise is sought.
-
-This is Columbus' egg: GNU LilyPond attaches "springs" to each
-column-pair. each spring has an equilibrium-position which is equal to
-the above mentioned distance, so
-
-spring (col1, col2) and spring (col2,col3) try to push column 1
-and 3 away (to a distance of 20pt) from each other, whereas the spring
-between col 1 and col 3 tries to pull those two together (to a
-distance of 14.1 pt). The net result of this pushing and pulling is an
-equilibrium situation (the pushing cancels the pulling), which can be
-calculated as the solution of Quadratic program: it is the solution
-with minimum potential energy, for you physicists out there.
-
-This algorithm for doing one line, gives a "badness" parameter for
-each line (the potential energy). Now one can use TeX's algorithm for
-making paragraphs (using this new version of "badness"): one should
-try to minimise the overall badness of a paragraph. GNU LilyPond also
-uses the concept of pre- and post-breaks.
-
-(actually, it is a bit more complicated: each column also has a
-minimum distance to other columns, to prevent symbols from running
-into symbols of other columns.)
-
+++ /dev/null
-article(links - Links to other related websites)(HWN and JCN)()
-
-sect(DESCRIPTION)
-
-This page contains links to organisations and ftp-sites, which may be
-of interest to LilyPond users.
-
-sect(WWW)
-
-nsubsect(LilyPond)
-
-description(
-dit(lurl(http://www.cs.uu.nl/people/hanwen/lilypond/))Han-Wen's site.
-dit(lurl(http://sca.uwaterloo.ca/lilypond/))The canadian mirror
-(thanks, Eric!)
-)
-
-subsect(Other)
-
-description(
-dit(lurl(http://www.gnu.org/))
- LilyPond is part of the GNU Project. The GNU project is the name
- of Richard Stallman's effort to create a freely available
- system of software.
-dit(lurl(http://www.zib.de/Visual/software/doc++/index.html))
- The documentation system for C++ sources, which is used for the
- LilyPond sources.
-dit(lurl(http://www.xs4all.nl/~jantien/yodl/index.html))
- LilyPond documentation is in Yodl. You'll need a recent
- development version from
- lurl(ftp://ftp.lilypond.org/pub/yodl/development).
-dit(lurl(http://www.iat.unc.edu/technology/music/music.html))
- An enormous collection of music related URLs
-dit(lurl(http://www.ram.org/ramblings/philosophy/fmp.html))
- Musings on free music, plus hints how to record your own (free) music.
-dit(lurl(http://www.geocities.com/Vienna/Studio/1714/))
- John Sankey has taken up the task of recording classical
- music, and distributing the results at no cost.
-)
-
-sect(Ftp)
-
-At this moment we have about one development-patchlevel per week.
-These development releases will be at
-
-itemize(
-it()lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/development)
-
-it()lurl(ftp://sca.uwaterloo.ca/pub/lilypond)
-
-it()lurl(ftp://ftp.lilypond.org/pub/lilypond)
-)
-
-Debian releases are located at
-lurl(http://cgi.debian.org/www-master/debian.org/Packages/stable/tex/lilypond.html)
-and
-lurl(ftp://ftp.debian.org/debian/dists/unstable/main/binary-i386/tex/lilypond_*.deb)
-
-Precompiled i386 RedHat RPMS are available from
-lurl(http://linux.umbc.edu/software/lilypond/rpms/).
-
-
-sect(News)
-
-The following newsgroups all contain material relevant to LilyPond
-itemize(
-
-it()lurl(news://comp.music.research)
-
-it()lurl(news://rec.music.compose)
-
-it()lurl(news://gnu.announce)
-
-it()lurl(news://comp.os.linux.announce)
-)
-
-sect(Mailing lists)
-
-
-includefile(mail.yo)
-
-
-sect(Backlinks)
-
-description(
-dit(lurl(http://sca.uwaterloo.ca/Mutopia/))
- Mutopia project (under construction).
-dit(lurl(http://www.ssc.com/linux/))
- The Number One Free Operating System Kernel: Linux
-dit(lurl( http://sound.condorow.net))
- Dave Philips' Linux sound applications page
-dit(lurl(http://www4.smart.net/~jcovey/scores.html))
- Jeff Covey's guitar music
-dit(lurl(http://www.home.fh-karlsruhe.de/~rost0001/web/musik/musik.html))
- Stochastic composing using LilyPond
-dit(lurl(http://www.medieval.org/emfaq/scores/software.html))
- More software for (early) music.
-dit(lurl(http://www.pbm.com/~lindahl/ravenscroft/modern))
- Transcriptions of the music of Thomas Ravenscroft, partly using
- LilyPond
-dit(lurl(http://www.redhat.com/))
- RedHat Software Inc. develops and markets a GNU/Linux distribution (of
- which we are avid users)
-)
-
-
+++ /dev/null
-
-For programs which are part of the GNU music project, the following
-mailing list have been setup:
-
-description(
-dit(info-gnu-music@gnu.org)
- A moderated list for information on the GNU Music project, to
- subscribe: send mail with subject "subscribe" to
- info-gnu-music-request@gnu.org.
-
- As this list is moderated, normal people should ask to
- nemail(David R. Linn)(drl@gnu.org) or
- nemail(Han-Wen)(hanwen@cs.uu.nl) to forward announces instead of
- sending it to info-gnu-music@gnu.org
-
-Since the GNU Music project currently only has LilyPond, this list is
-mainly for announcing new versions of LilyPond.
-
-lurl(http://www.mail-archive.com/info-gnu-music@gnu.org)
-
-dit(help-gnu-music@gnu.org)
- For help with programs from the GNU music project. To subscribe: send
- mail with subject "subscribe" to
- email(help-gnu-music-request@gnu.org)
-
- Since the GNU Music project currently only has LilyPond, this list is mainly about using and extending LilyPond.
-
- lurl(http://www.mail-archive.com/help-gnu-music@gnu.org)
-
-
-dit(bug-gnu-music@gnu.org)
- If you have bugreports, you should send them to this list. If you want
- to read all bugreports, you should subscribe to this list. To
- subscribe: send mail with subject "subscribe" to
- email(bug-gnu-music-request@gnu.org)
- lurl(http://www.mail-archive.com/bug-gnu-music@gnu.org)
-dit(gnu-music-discuss@gnu.org,)
- For discussions concerning the GNU Music project, to subscribe: send
- mail with subject "subscribe" to
- email(gnu-music-discuss-request@gnu.org)
- This list is archived at
- lurl(http://www.mail-archive.com/gnu-music-discuss@gnu.org)
-)
-
-Announces of new versions will be sent to info-gnu-music and
-gnu-music-discuss.
-
+++ /dev/null
-# Documentation/man/Makefile
-
-depth = ../..
-
-STEPMAKE_TEMPLATES=documentation install-out
-SECTION=1
-MANTXT = $(addprefix $(outdir)/, $(addsuffix .txt,$(basename $(TEXINFO_FILES) .texinfo)))
-MANGROFF = $(addprefix $(outdir)/, $(addsuffix .$(SECTION),$(basename $(YO_FILES) .yo)))
-
-OUT_DIST_FILES += $(MANGROFF)
-
-include $(depth)/make/stepmake.make
-
-default: $(MANGROFF)
-
-INSTALLATION_OUT_FILES=$(MANGROFF)
-INSTALLATION_OUT_DIR=$(mandir)/man$(SECTION)
-
-local-WWW: $(MANGROFF:.1=.html)
- $(PYTHON) $(step-bindir)/ls-latex.py --package=$(topdir) --title 'Manual pages for LilyPond' $(YO_FILES) \
- | sed "s!$(outdir)/!!g" > $(outdir)/index.html
- $(PYTHON) $(step-bindir)/add-html-footer.py --package=$(topdir) $(outdir)/index.html
+++ /dev/null
-
-mailto(janneke@gnu.org)
-COMMENT(
- (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)())
-)
-manpage(LilyPond)
- (1)
- (1999)
- (abc2ly)
- (The LilyPond package)
-
-metalC(Automatically generated by yodl(1) from abc2ly.yo.)
-
-manpagename(abc2ly)(convert ABC to Mudela)
-
-manpagedescription()
-
-abc2ly translates an ABC file (see
-lurl(http://www.gre.ac.uk/~c.walshaw/abc2mtex/)) input file to Mudela
-(GNU LilyPond source format). abc2ly is part of the GNU LilyPond
-music typesetting package.
-
-manpagesynopsis()
-
- abc2ly [options] abc-file
-
-manpageoptions()
-
-description(
-dit(-h, --help,)
- Show a summary of usage.
-dit(-o, --output=file(FILE),)
- Set file(FILE) as default output.
-)
-
-manpagesection(DISCLAIMER)
-
-abc2ly is copyright 1996, 1997 by its authors. abc2ly is distributed
-as part of GNU LilyPond, under the terms of the GNU General Public
-License. abc2ly is provided without any warranty what so ever.
-abc2ly may be freely distributed. For further information consult
-the GNU General Public License, from the file file(COPYING).
-
-manpageseealso()
-
-description(
-dit(bf(lilypond)(1))
- The GNU LilyPond music typesetter.
-)
-
-manpagebugs()
-
-file(abc2ly) gets order of slurs, ties and chord endings wrong. Some
-of the header fields are not fully supported. Music with lyrics will
-print the lyrics doubly. file(abc2ly) also gets confused about tuplet
-endings. file(abc2ly) does not use relative octaves.
-
-manpageauthor()
-
-Please consult the documentation file file(AUTHORS) for more detailed
-information, and small contributions.
-
-nemail(Jan Nieuwenhuizen)(janneke@gnu.org), lurl(http://www.xs4all.nl/~jantien)
-nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/~hanwen)
+++ /dev/null
-
-mailto(janneke@gnu.org)
-COMMENT(ugh, should be automated)
-COMMENT(urg
- (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)())
-)
-manpage(convert-mudela)
- (1)
- (1999)
- (The LilyPond package)
- (convert-mudela)
-
-metalC(Automatically generated by yodl(1) from convert-mudela.yo.)
-
-manpagename(convert-mudela)(convert-mudela to newer versions)
-
-convert-mudela sequentially applies different mudela-conversions to
-upgrade a Mudela input file.
-
-manpagedescription()
-
-Upgrade a Mudela input file from FROM_PATCHLEVEL to TO_PATCHLEVEL.
-If no files are given, the standard input and output are used.
-
-manpagesynopsis()
-
- convert-mudela [options] [files]
-
-manpageoptions()
-description(
-dit(--output)
- The output file to write.
-dit(--edit)
- Do an inline edit of the input file. override code(--output)
-dit(--show-rules)
- shows all known conversions, and exit
-dit(--from=FROM_PATCHLEVEL)
- Set the level to convert from. If this is not set, convert-mudela will
- guess this, on the basis of code(\version) strings in the file
-dit(--to=TO_PATCHLEVEL)
- Set the goal version of the conversion. It defaults to the latest
- available version.
-)
-
-manpagesection(BUGS)
-
-Not all language changes are handled. Multiple output options won't
-work.
-
-convert-mudela is written in python, so you have install
-url(python)(http://www.python.org).
-
-
-manpageauthor()
-
-nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/people/hanwen)
-
+++ /dev/null
-COMMENT(i don't get this)
-mailto(janneke@gnu.org)
-COMMENT(
- (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)())
-)
-
-redef(cindex)(1)(\
- whenlatex(latexcommand(\index{)ARG1+latexcommand(}))\
- whentexinfo(XXnl()texinfocommand(@cindex )ARG1XXnl())\
-)
-
-redef(cindex)(1)(\
- whenlatex(latexcommand(\index{)ARG1+latexcommand(}))\
- whentexinfo(XXnl()texinfocommand(@cindex )ARG1XXnl())\
-)
-
-manpage(LilyPond)
- (1)
- (1999)
- (The LilyPond package)
- (The GNU Project Music Typesetter)
-
-metalC(Automatically generated by yodl(1) from lilypond.yo.)
-
-manpagename(LilyPond)(the GNU Music Typesetter)
-cindex(LilyPond)
-
-manpagesynopsis()
- bf(lilypond) [OPTION]... [MUDELA-FILE]...
-
-manpagedescription()
-
-includefile(../BLURB.in)
-
-manpageoptions()
-description(
-dit(-f,--format=)
- Output format for sheet music. Choices are tex (for TeX
- output), ps (for PostScript) and scm (for GUILE)
-dit(-I,--include=)
- add file(FILE) to the search path for input files.
-dit(-m,--midi)
- Disable TeX output. If you have a \midi definition, it will do the
- midi output only.
-dit(-M,--dependencies)
- Also output rules to be included in Makefile.
-dit(-d,--debug)
- Turn debugging info on. GNU LilyPond reads the file file(.dstreamrc),
- which lists what functions and classes may produce copious debugging
- output.
-dit(-s,--safe)
- Disallow untrusted code(\include) directives, backslashes in TeX()
-code and named output.
-dit(-t,--test)
- Switch on any experimental features. Not for general public use.
-dit(-w,--warranty)
- Show the warranty with which GNU LilyPond comes. (It comes with
- bf(NO WARRANTY)!)
-dit(-o,--output=FILE)
- Set the default output file to file(FILE).
-dit(-h,--help)
- Show a summary of usage.
-dit(-i,--init=FILE)
- Set init file to file(FILE) (default: file(init.ly)).
-dit(--include, -I=DIRECTORY)
- Add file(DIRECTORY) to the search path for input files.
-dit(--ignore-version, -V)
- Make the incompatible mudela version warning non-fatal.
-)
-
-manpagesection(FEATURES)
-
-This is an overview of the features that GNU LilyPond supports. For
-details on how to use them, you should consult the Mudela tutorial,
-which is included with the package.
-
-
-itemize(
-it()ASCII script input, with identifiers (for music reuse),
- customizable notenames, customisable fontset.
-it()MIDI output lets you check if you have entered the correct notes.
-it()MIDI to Mudela conversion through the mi2mu program.
-it()Multiple staffs in one score. Each staff can have different time signatures.
-it()Beams, slurs, ties, chords, super/subscripts (accents and text)
- triplets, general n-plet (triplet, quadruplets, etc.), lyrics,
- transposition, dynamics (both absolute and hairpin style).
-it()Multiple voices within one staff; beams optionally shared
- between voices. Up to four voices is handled cleanly.
-it()Multiple scores within one input file. Each score is output to
- a different file.
-it()Clef changes, meter changes, cadenza-mode, key changes, repeat bars.
-)
-
-manpagesection(DISCLAIMER)
-
-GNU LilyPond is copyright 1996-1999 by its authors. GNU LilyPond is
-distributed under the terms of the GNU General Public License. GNU LilyPond
-is provided without any warranty what so ever.
-GNU LilyPond may be freely distributed. For further information consult
-the GNU General Public License, from the file file(COPYING).
-
-manpagesection(PROBLEMS)
-
-There is an extensive list of todoes and bugs. See the file
-file(TODO) distributed with the sources. If you have a problem you
-should try to find out
-
-itemize(
-it()If the bug has been fixed in a newer release.
-it()If the bug has been found earlier, consult file(TODO) and file(BUGS).
-)
-
-If you have found a bug, then we would appreciate it if you sent a
-bugreport.
-
-itemize(
-it()Send a copy of the input which causes the error.
-it()Send a description of the platform you use.
-it()Send a description of the LilyPond version you use
- (with compile/configure options please).
-it()Send a description of the bug itself.
-it()Send it to email(bug-gnu-music@gnu.org); you don't have to be subscribed
- to this mailinglist.
-)
-
-manpagefiles()
-description(
-dit(file(init.ly))
- The initialisation file with symbol tables etc. It
- includes files from the directory
- file(PREFIX/share/lilypond/ly/). (file(PREFIX) typically is file(/usr/local)
-))
-
-manpagesection(environment)
-
-description(
-dit(LILYINCLUDE)
- additional directories for finding lilypond data. The
- format is like the format of file(PATH).
-dit(LILYPREFIX)
- [FIXME]
-dit(LANG)
- selects the language for the warning messages of LilyPond.
-)
-
-manpagebugs()
-
-Lots of them. See file(TODO) and file(BUGS)
-
-manpageseealso()
-
-LilyPond comes with various other documentation files. They are
-included in the source package.
-
-A further source for information is the website, which can be found at
-lurl(http://www.lilypond.org/). The website contains on-line versions
-of the documentation
-
-
-GNU LilyPond is updated very frequently, the latest version is always
-available at: lurl(ftp://ftp.cs.uu.nl/pub/GNU/LilyPond). This FTP
-site is mirrored at a number of sites; consult the project web pages
-for information about mirrors.
-
-For programs which are part of the GNU music project, the following
-mailing list have been setup:
-
-description(
-dit(email(info-gnu-music@gnu.org))
- For information on the GNU Music project, to subscribe: send mail with
- subject "subscribe" to email(info-gnu-music-request@gnu.org)
-dit(email(help-gnu-music@gnu.org))
- For help with programs from the GNU music project. To subscribe: send
- mail with subject "subscribe" to email(help-gnu-music-request@gnu.org)
-dit(email(bug-gnu-music@gnu.org))
- If you have bugreports, you should send them to this list. If you want
- to read all bugreports, you should subscribe to this list. To
- subscribe: send mail with subject "subscribe" to
- email(bug-gnu-music-request@gnu.org)
-dit(email(gnu-music-discuss@gnu.org))
- For discussions concerning the GNU Music project, to subscribe: send
- mail with subject "subscribe" to
- email(gnu-music-discuss-request@gnu.org)
-)
-
-Announces of new versions will be sent to info-gnu-music and
-gnu-music-discuss.
-
-manpagesection(REMARKS)
-
-GNU LilyPond has no connection with the music package Rosegarden, other
-than the names being similar :-)
-
-manpageauthor()
-cindex(Author)
-
-itemize(
-it()nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl)
- lurl(http://www.cs.uu.nl/people/hanwen)
-it()nemail(Jan Nieuwenhuizen)(janneke@gnu.org)
- lurl(http://www.xs4all.nl/~jantien)
-)
-
-Please consult the documentation file file(AUTHORS) for more detailed
-information, and small contributions.
+++ /dev/null
-mailto(daboys@austin.rr.com)
-manpage(LilyPond)
- (1)
- (1999)
- (The LilyPond package)
- (Ly2dvi)
-
-metalC(Automatically generated by yodl(1) from ly2dvi.yo.)
-
-manpagename(Ly2dvi)(Python utility to convert mudela to DVI)
-
-manpagedescription()
-ly2dvi is a Python script which creates input file for LaTeX,
-based on information from the output files from LilyPond.
-The script handles multiple files. If a mudela file name is
-specified LilyPond is run to make an output (TeX) file.
-
-One or more LaTeX files are created, based on information found
-in the output (TeX) files, and latex is finally run to create
-one or more DVI files.
-
-The majority of this utility came from a bourne script written by Jan
-Arne Fagertun name file(ly2dvi).
-
-manpagesynopsis()
-
- ly2dvi [options] inputfile[.ly] [....]
-
-manpageoptions()
-
-description(
-dit(-D,--debug)
- Set debug mode. There are two levels - in level one some debug
- info is written, in level two the command bf(set -x) is run, which
- echoes every command in the ly2dvi script.
-dit(-F,--headers=)
- Name of additional LaTeX headers file. This is included in the
- tex file at the end of the headers, last line before code(\begin{document})
-dit(-H,--Heigth=)
- Set paper heigth (points). Used together with width and LaTeX name of
- papersize in case of papersize unknown to ly2dvi.
-dit(-K,--keeplilypond)
- Keep LilyPond output after the run.
-dit(-L,--landscape)
- Set landscape orientation - portrait is the default.
- (bf(-L) produces code(\usepackage[landscape]{article}))
-dit(-N,--nonumber)
- Switch off page numbering.
-dit(-O,--orientation=)
- Set orientation landscape - obsolete, use bf(-L) instead.
-dit(-P,--postscript)
- In addition to the DVI file, also Generate a postsript file.
-dit(-W,--Width=)
- Set paper width (points). Used together with heigth and LaTeX name of
- papersize in case of papersize unknown to ly2dvi.
-dit(-d,--dependencies)
- Tell lilypond to make dependencies file.
-dit(-h,--help)
- Print help.
-dit(-k,--keeply2dvi)
- Keep the LaTeX file after the run.
-dit(-l,--language=)
- Specify LaTeX language.
- (bf(-l norsk) produces code(\usepackage[norsk]{babel})).
-dit(-o,--output=)
- Set output directory.
-dit(-p,--papersize=)
- Specify papersize.
- (bf(-p a4) produces code(\usepackage[a4paper]{article}))
-dit(-s,--separate)
- Normally all output files are included into one LaTeX file.
- With this switch all files are run separately, to produce one
- DVI file for each.
-)
-
-manpagesection(Features)
-
-ly2dvi responds to several parameters specified in the mudela
-file. They are overridden by corresponding command line options.
-
-description(
-dit(language="";)
- Specify LaTeX language
-dit(latexheaders="";)
- Specify additional LaTeX headers file
-dit(orientation="";)
- Set orientation.
-dit(paperlinewidth="";)
- Specify the width (pt, mm or cm) of the printed lines.
-dit(papersize="";)
- Specify name of papersize.
-)
-
-manpagesection(Environment)
-
-description(
-dit(LILYPONDPREFIX)
- Sets the root directory of the LilyPond installation
-dit(LILYINCLUDE)
- Additional directories for input files.
-dit(TMP)
- Temporary directory name. Default is /tmp
-)
-
-manpagesection(Files)
-
-file(titledefs.tex) is inspected for definitions used to extract
-additional text definitions from the mudela file. In the current
-version the following are defined:
-
-description(
-dit(title)
- The title of the music. Centered on top of the first page.
-dit(subtitle)
- Subtitle, centered below the title.
-dit(poet)
- Name of the poet, leftflushed below the below subtitle.
-dit(composer)
- Name of the composer, rightflushed below the subtitle.
-dit(metre)
- Meter string, leftflushed below the below poet.
-dit(opus)
- Name of the opus, rightflushed below the below composer.
-dit(arranger)
- Name of the arranger, rightflushed below the opus.
-dit(instrument)
- Name of the instrument, centered below the arranger
-dit(piece)
- Name of the piece, leftflushed below the instrument
-)
-
-file($LILYPONDPREFIX/share/.lilyrc $HOME/.lilyrc ./.lilyrc) are files
-to set up default running conditions. On Windows OS initialization
-files are named file(_lilyrc). The file syntax is as follows:
-
-verb(VARIABLE-NAME=VALUE)
-
-Where bf(VARIABLE-NAME) is the name of the variable documented below
-and bf(VALUE) is either a string, a 1, or a 0. All files are parsed,
-in the shown sequence. In the current version the following are
-allowed:
-
-description(
-dit(DEBUG=value)
-This turns off (default) or on the debug capabilities. Possible
-values are 0 (off) and 1 (on).
-dit(DEPENDENCIES=value)
-This turns off (default) or on the ability to generate a Makefile
-dependency list. Possible values are 0 (off) and 1 (on).
-dit(KEEPLILYPOND=value)
-This turns off (default) or on the ability to keep the log file
-associated with the LilyPond job. Possible values are 0 (off) and 1
-(on).
-dit(KEEPLY2DVI=value)
-This turns off (default) or on the ability to keep the temporary files
-that are generated by the ly2dvi job. Possible values are 0 (off) and
-1 (on)
-dit(LANGUAGE=value)
-Specify LaTeX language. Possible value is a valid LaTeX language.
-dit(LATEXHF=value)
-Specify additional LaTeX headers file. Possible value is a file
-specification.
-dit(LILYINCLUDE=value)
-Additional directories for input files. Possible value is a delimited
-directory path list.
-dit(LILYPONDPREFIX=value)
-This defines the LilyPond root directory. Possible value is a valid
-directory specification to the LilyPond distribution location.
-dit(NONUMBER=value)
-This turns off (default) or on the page numbering capability.
-Possible values are 0 (page numbering enabled) and 1 (page numbering
-disabled).
-dit(ORIENTATION=value)
-This sets the image orientation. Possible values are
-portrait (default) and landscape.
-dit(OUTPUTDIR=value)
-This defines the directory where the resultant files will be
-generated. Possible value is a valid directory specification.
-Default is the current working directory.
-dit(PAPERSIZE=value)
-This defines the papersize the image will be sized to fit. Possible
-values are a0, a1, a2, a3, a4 (default), a5, a6, a7, a8, a9, a10, b0,
-b1, b2, b3, b4, b5, archA, archB, archC, archD, archE, flsa, flse,
-halfletter, ledger, legal, letter, or note.
-dit(PHEIGHT=value)
-Specify paperheight (points - an inch is 72.27, a cm is 28.453 points).
-dit(POSTSCRIPT=value)
-This turns off (default) or on the capability of additionally
-generating a postscript file. Possible values are 0 (off) and 1 (on).
-dit(PWIDTH=value)
-Specify paperwidth (points - an inch is 72.27, a cm is 28.453 points).
-dit(SEPARATE=value)
-This turns off (default) or on the capability of generating multiple
-dvi and postscript files from multiple source files. The default is
-to generate a concatenation of the source files. Possible values are
-0 (single file) and 1 (separate files).
-dit(TMP=value)
-This defines the emporary directory. Actually this is not used at the
-present. Possible value is a valid directory specification that is
-writable to the user.
-)
-
-manpagesection(Initialization Sequence)
-The initialization process reads inputs for several sources. Below is
-a list of priorities for lowest to hightest proirity.
-
-itemize(
-it() Program's defaults
-it() Values found in LilyPond output file
-it() Environment variables
-it() $LILYPONDPREFIX/share/lilypond/.lilyrc
-it() $HOME/.lilyrc
-it() ./.lilyrc
-it() command line options
-)
-
-Note that this differs slightly from the original bourne shell
-version.
-
-
-manpagesection(See Also)
-
-lilypond(1), tex(1), latex(1)
-
-manpagesection(Bugs)
-
-If you have found a bug, you should send a bugreport.
-
-itemize(
-it()Send a copy of the input which causes the error.
-it()Send a description of the platform you use.
-it()Send a description of the LilyPond and ly2dvi version you use.
-it()Send a description of the bug itself.
-it()Send it to email(bug-gnu-music@gnu.org) (you don't have to subscribe
- to this mailinglist).
-)
-
-manpagesection(Remarks)
-
-Many papersizes are now supported. Information on other sizes
-(LaTeX names, horizontal and vertical sizes) should be mailed to
-the author or to the mailing list.
-
-Supported papersizes are:
-
-a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, archA, archB, archC, archD,
-archE, b0, b1, b2, b3, b4, b5, flsa, flse, halfletter, ledger, legal,
-letter, note
-
-manpageauthor()
-Python Version author:
-nemail(Jeffrey B. Reed)(daboys@austin.rr.com),
-lurl(http://home.austin.rr.com/jbr/jeff/lilypond/)
-
-Original bourne shell version author:
-nemail(Jan Arne Fagertun)(Jan.A.Fagertun@energy.sintef.no),
-lurl(http://www.termo.unit.no/mtf/people/janaf/)
-
-
-
+++ /dev/null
-
-mailto(janneke@gnu.org)
-COMMENT(
- (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)())
-)
-manpage(LilyPond)
- (1)
- (1999)
- (midi2ly)
- (The LilyPond package)
-
-metalC(Automatically generated by yodl(1) from midi2ly.yo.)
-
-manpagename(midi2ly)(convert MIDI to bf(mudela))
-
-manpagedescription()
-midi2ly translates a MIDI input file to Mudela (GNU LilyPond source
-format). midi2ly is part of the GNU LilyPond music typesetting package.
-
-manpagessynopsis()
-
- midi2ly [options] midi-file
-
-manpageoptions()
-
-description(
-dit(-b, --no-quantify,)
- Write exact durations, e.g.: `a4*385/384'.
-dit(-D, --debug,)
- Print lots of debugging stuff.
-dit(-h, --help,)
- Show a summary of usage.
-dit(-I, --include=file(DIR),)
- Add DIR to search path.
-dit(-k, --key=ACC[:MINOR],)
- Set default key. ACC > 0 sets number of sharps; ACC < 0 sets number
- of flats. A minor key is indicated by ":1".
-dit(-n, --no-silly,)
- Assume no plets or double dots, assume smallest (reciprocal) duration 16.
-dit(-o, --output=file(FILE),)
- Set file(FILE) as default output.
-dit(-p, --no-plets,)
- Assume no plets.
-dit(-q, --quiet,)
- Be quiet.
-dit(-s, --smallest=N,)
- Assume no shorter (reciprocal) durations than N.
-dit(-v, --verbose,)
- Be verbose.
-dit(-w, --warranty,)
- Show the warranty with which midi2ly comes. (It comes with bf(NO WARRANTY)!)
-dit(-x, --no-double-dots,)
- Assume no double dotted notes.
-)
-
-manpagesection(DISCLAIMER)
-
-midi2ly is copyright 1996, 1997 by its authors. midi2ly is distributed
-as part of GNU LilyPond, under the terms of the GNU General Public
-License. midi2ly is provided without any warranty what so ever.
-midi2ly may be freely distributed. For further information consult
-the GNU General Public License, from the file file(COPYING).
-
-manpageseealso()
-
-description(
-dit(bf(lilypond)(1))
- The GNU LilyPond music typesetter.
-)
-
-manpageauthor()
-
-Please consult the documentation file file(AUTHORS) for more detailed
-information, and small contributions.
-
-nemail(Jan Nieuwenhuizen)(janneke@gnu.org), lurl(http://www.xs4all.nl/~jantien)
-
+++ /dev/null
-
-mailto(janneke@gnu.org)
-COMMENT(
- (PIPETHROUGH(echo -n `date '+%d/%b/%y'|tr '[a-z]' '[A-Z]'`)())
-)
-manpage(LilyPond)
- (1)
- (1999)
- (The LilyPond package)
- (mudela-book)
-
-metalC(Automatically generated by yodl(1) from mudela-book.yo.)
-
-manpagename(mudela-book)(integrate LaTeX and mudela)
-
-manpagesynopsis() bf(mudela-book) [options] inputfile
-
-manpagedescription() file(mudela-book) is a script that helps
-integrating mudela and LaTeX. mudela-book runs LilyPond on
-fragments of mudela in your source file, and includes the results into
-document that can be processed with LaTeX. The result is a text
-document with formatted music integrated.
-
-Lilypond will by default create all output files in directory file(out).
-The file to give to latex has ext file(.latex).
-
-bf(About the input)
-
-If the file contains the ``block''
-
-verb(
- \begin{mudela}
- CONTENTS
- \end{mudela}
-)
-
-then LilyPond is run on CONTENTS. mudela-book puts the result back,
-surrounded by code(\preMudelaExample) and code(\postMudelaExample)
-commands. code(\preMudelaExample) and code(posMudelaExample) is
-defined to nothing by default, and the user can redefine them
-to whatever he wants.
-
-code(\begin) takes the following options:
-
-description(
-dit(eps)
- the music is created as eps graphics that can be inserted in
- the middle of a text line, not only as a separate paragraph
-dit(verbatim)
- CONTENTS is copied into the TeX source enclosed in a verbatim block.
-dit(11pt, 13pt, 16pt, 20pt, 26pt)
- set the fontsize to use for the music
-dit(singleline)
- linewidth = -1.
-dit(multiline)
- linewidth = textwidth
-dit(fragment)
-dit(nonfragment)
- Override mudela-book autodetection of what type of code is in the
- mudela block, voice contents or complete code.
-)
-
-
-manpageoptions()
-
-startdit()
-
-dit(--default-mudela-fontsize=??pt)
- Set the fontsize to use for mudela if no fontsize is given
- as option.
-dit(--force-mudela-fontsize=??pt)
- Force all mudela to use this fontsize, overriding options
- given to \begin{mudela}
-dit(--outname=FILE)
- The name of LaTeX() file to output. If this option is not given,
-the output name derived from the input name.
-dit(--outdir=DIRECTORY)
- The name of the directory to output lilypond output and input to.
- This must be a name; the subdirectory will be created in the cwd. [FIXME]
-dit(--help)
- Print a short help message
-dit(--dependencies)
- Write dependencies to outdir/filename.dep
-dit(--force-verbatim)
- Make all mudela verbatim.
-dit(--initfile=FILE)
- read command definitions from file(FILE)
-enddit()
-
-manpagefiles()
- See file(Documentation/tex/out/mudela-book-doc.dvi) for more info.
- You have to install LaTeX.
- file(mudela-book) is written in python 1.5, so you have to install
- url(python)(http://www.python.org).
-
-manpagebugs()
-
-The LaTeX \includeonly{...} command is ignored.
-
-You get trouble if you use the --force-verbatim option and have some
-music in \footnote{...} or \marginpar{...}.
-
-Ignores almost all LaTeX commands that changes margins and linewidths.
-
-manpageauthor()
-
-nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl), lurl(http://www.cs.uu.nl/people/hanwen)
-
-nemail(Tom Cato Amundsen)(tomato@xoommail.com)
+++ /dev/null
-COMMENT(
-URG
-don't try to make html from this
-)
-whentexinfo(
-nodetext(Your Softs.)
-chapter(Programs)
-
-COMMENT(prepare for texinfoing manpages)
-redef(manpage)(5)()
-redef(manpagename)(2)(nodeprefix()nodetext(ARG2)chapter(ARG1)nodeprefix(ARG1 ))
-redef(manpageauthor)(0)(sect(Authors))
-redef(manpagesection)(1)(sect(ARG1))
-
-redef(includefile)(1)(INCLUDEFILE(man/ARG1))
-includefile(convert-mudela.yo)
-includefile(lilypond.yo)
-includefile(ly2dvi.yo)
-includefile(midi2ly.yo)
-includefile(mudela-book.yo)
-)
+++ /dev/null
-\documentclass{article}
-
-\begin{document}
-
-\begin[eps,intertext="this is that",verbatim]{mudela}
-\score { \notes {c4 g4 }}
-\end{mudela}
-
-\begin{verbatim}
-\begin[eps,intertext="this is that",verbatim]{mudela}
-\score { \notes {a a }}
-\end{mudela}
-\end{verbatim}
-
-chit chat chot \verb|\mudela{a4 b}| \mudela{a b} and \mudelafile[fragment]{testje.fly}.
-
-\end{document}
+++ /dev/null
-COMMENT( URG don't try to make html from this)
-
-whentexinfo(
-
-nodetext(Your Rights.) COMMENT(set different text)
-chapter(Copying)
-LilyPond is Free Software. See file(COPYING) for details.
-
-
-COMMENT(prepare for texinfoing manpages)
-redef(manpage)(5)()
-redef(manpagename)(2)(nodetext(ARG2)chapter(ARG1))
-redef(manpageauthor)(0)(sect(Authors))
-redef(manpagesection)(1)(sect(ARG1))
-
-COMMENT(prepare for texinfoing articles)
-redef(article)(3)(chapter(ARG1))
-redef(latexlayoutcmds)(1)()
-redef(htmlbodyopt)(2)()
-
-COMMENT(redef(includefile)(1)(INCLUDEFILE(man/ARG1)))
-includefile(programs.yo)
-
-nodeprefix()
-redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Tutorial ))
-COMMENT(yodl2texinfo should be able to cope now, although ugly...)
-redef(article)(3)(chapter(ARG1))
-
-redef(includefile)(1)(INCLUDEFILE(tex/ARG1))
-includefile(tutorial.yo)
-
-redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Refman ))
-COMMENT(yodl2texinfo should be able to cope now, although ugly...)
-redef(article)(3)(chapter(ARG1))
-
-redef(includefile)(1)(INCLUDEFILE(tex/ARG1))
-includefile(reference-manual.yo)
-
-redef(article)(3)(nodeprefix()chapter(ARG1)nodeprefix(Mutopia ))
-COMMENT(yodl2texinfo should be able to cope now, although ugly...)
-redef(article)(3)(chapter(ARG1))
-
-COMMENT(
-
-dropped? --jcn
-
-redef(includefile)(1)(INCLUDEFILE(ARG1))
-includefile(mutopia.yo)
-
-)
-
-nchapter(Concept Index)
-COMMENT( urg makeindex())
-printindex()
-)
+++ /dev/null
-#!@PYTHON@
-# All non-english comments are NOT in swedish, they are norwegian!
-
-# TODO: center option (??)
-# * the verbatim option should not be visible in the created latex file
-# * what the h.. does castingalgorithm do/mean???
-# * the following fails because mudelabook doesn't care that the
-# last } after \end{mudela} finishes the marginpar:
-# \marginpar{
-# \begin{mudela}[fragment]
-# c d e f g
-# \end{mudela}}
-# * fragments should know about margins
-
-# log:
-# 0.3:
-# rewrite in Python.
-# 0.4:
-# much rewritten by new author. I think the work has been split more
-# logical between different classes.
-# 0.4.1:
-# - cleanup
-# - speedup, do all mudela parsing at the same time to avoid multiple
-# guile startup that takes some seconds on my computer
-
-import os
-import string
-import re
-import getopt
-import sys
-
-outdir = 'out'
-program_version = '0.4.1'
-
-out_files = []
-
-fontsize_i2a = {11:'eleven', 13:'thirteen', 16:'sixteen', 20:'twenty', 26:'twentysix'}
-fontsize_pt2i = {'11pt':11, '13pt':13, '16pt':16, '20pt':20, '26pt':26}
-
-begin_mudela_re = re.compile ('^ *\\\\begin{mudela}')
-extract_papersize_re = re.compile('\\\\documentclass[\[, ]*(\w*)paper[\w ,]*\]\{\w*\}')
-extract_fontsize1_re = re.compile('\\\\documentclass\[[^\]]*\]\{[^\}]*\}')
-extract_fontsize2_re = re.compile('[ ,\[]*([0-9]*)pt')
-begin_mudela_opts_re = re.compile('\[[^\]]*\]')
-end_mudela_re = re.compile ('^ *\\\\end{mudela}')
-section_re = re.compile ('\\\\section')
-chapter_re = re.compile ('\\\\chapter')
-input_re = re.compile ('^\\\\input{([^}]*)')
-include_re = re.compile ('^\\\\include{([^}]*)')
-begin_document_re = re.compile ('^ *\\\\begin{document}')
-documentclass_re = re.compile('\\\\documentclass')
-twocolumn_re = re.compile('\\\\twocolumn')
-onecolumn_re = re.compile('\\\\onecolumn')
-preMudelaExample_re = re.compile('\\\\def\\\\preMudelaExample')
-postMudelaExample_re = re.compile('\\\\def\\\\postMudelaExample')
-boundingBox_re = re.compile('%%BoundingBox: ([0-9]*) ([0-9]*) ([0-9]*) ([0-9]*)')
-
-def file_exist_b(name):
- try:
- f = open(name)
- except IOError:
- return 0
- f.close ()
- return 1
-
-def ps_dimention(fname):
- fd = open(fname)
- lines = fd.readlines()
- for line in lines:
- s = boundingBox_re.search(line)
- if s:
- break
- return (int(s.groups()[2])-int(s.groups()[0]),
- int(s.groups()[3])-int(s.groups()[1]))
-
-
-class CompileStatus:
- pass
-class SomethingIsSeriouslyBroken:
- pass
-
-def file_mtime (name):
- return os.stat (name)[8] #mod time
-
-def need_recompile_b(infile, outfile):
- indate = file_mtime (infile)
- try:
- outdate = file_mtime (outfile)
- return indate > outdate
- except os.error:
- return 1
-
-#
-# executes os.system(command) if infile is newer than
-# outfile or outfile don't exist
-#
-def compile (command, workingdir, infile, outfile):
- "Test if infile is newer than outfile. If so, cd to workingdir"
- "and execute command"
- indate = file_mtime (workingdir+infile)
- try:
- outdate = file_mtime (workingdir+outfile)
- recompile = indate > outdate
-
- except os.error:
- recompile = 1
-
- if recompile:
- sys.stderr.write ('invoking `%s\'\n' % command)
- if workingdir == '':
- status = os.system (command)
- else:
- status = os.system ('cd %s; %s' %(workingdir, command))
- if status:
- raise CompileStatus
-
-class Properties:
- #
- # init
- #
- def __init__(self):
- self.__linewidth = {
- 1: {'a4':{10: 345, 11: 360, 12: 390},
- 'a5':{10: 276, 11: 276, 12: 276},
- 'b5':{10: 345, 11: 356, 12: 356},
- 'letter':{10: 345, 11: 360, 12: 390},
- 'legal': {10: 345, 11: 360, 12: 390},
- 'executive':{10: 345, 11: 360, 12: 379}},
- 2: {'a4':{10: 167, 11: 175, 12: 190},
- 'a5':{10: 133, 11: 133, 12: 133},
- 'b5':{10: 167, 11: 173, 12: 173},
- 'letter':{10: 167, 11: 175, 12: 190},
- 'legal':{10: 167, 11: 175, 12: 190},
- 'executive':{10: 167, 11: 175, 12: 184}}}
- # >0 --> force all mudela to this pt size
- self.force_mudela_fontsize = 0
- self.force_verbatim_b = 0
- self.__data = {
- 'mudela-fontsize' : {'init': 16},
- 'papersize' : {'init': 'a4'},
- 'num-column' : {'init': 1},
- 'tex-fontsize' : {'init': 11}
- }
- def clear_for_new_file(self):
- for var in self.__data.keys():
- self.__data[var] = {'init': self.__data[var]['init']}
- def clear_for_new_block(self):
- for var in self.__data.keys():
- if self.__data[var].has_key('block'):
- del self.__data[var]['block']
- def __get_variable(self, var):
- if self.__data[var].has_key('block'):
- return self.__data[var]['block']
- elif self.__data[var].has_key('file'):
- return self.__data[var]['file']
- else:
- return self.__data[var]['init']
- def setPapersize(self, size, requester):
- self.__data['papersize'][requester] = size
- def getPapersize(self):
- return self.__get_variable('papersize')
- def setMudelaFontsize(self, size, requester):
- self.__data['mudela-fontsize'][requester] = size
- def getMudelaFontsize(self):
- if self.force_mudela_fontsize:
- return self.force_mudela_fontsize
- return self.__get_variable('mudela-fontsize')
- def setTexFontsize(self, size, requester):
- self.__data['tex-fontsize'][requester] = size
- def getTexFontsize(self):
- return self.__get_variable('tex-fontsize')
- def setNumColumn(self, num, requester):
- self.__data['num-column'][requester] = num
- def getNumColumn(self):
- return self.__get_variable('num-column')
- def getLineWidth(self):
- return self.__linewidth[self.getNumColumn()][self.getPapersize()][self.getTexFontsize()]
-
-
-class Mudela_output:
- def __init__ (self, basename):
- self.basename = basename
- self.temp_filename = "%s/%s" %(outdir, 'mudela-temp.ly')
- self.file = open (self.temp_filename, 'w')
- # 'tex' or 'eps'
- self.graphic_type = 'tex'
- self.fragment = 0
- def write (self, line):
- # match only if there is nothing but whitespace before \begin HACK
- if re.search('^\s*\\\\begin{mudela}', line):
- self.scan_begin_statement(line)
- self.write_red_tape()
- else:
- self.file.write (line)
- def scan_begin_statement(self, line):
- r = begin_mudela_opts_re.search(line)
- if r:
- o = r.group()[1:][:-1]
- optlist = re.compile('[ ,]*').split(o)
- else:
- optlist = []
- if 'floating' in optlist:
- self.graphic_type = 'eps'
- else:
- self.graphic_type = 'tex'
- if 'fragment' in optlist:
- self.fragment = 1
- else:
- self.fragment = 0
- for pt in fontsize_pt2i.keys():
- if pt in optlist:
- Props.setMudelaFontsize(fontsize_pt2i[pt], 'block')
- def write_red_tape(self):
- self.file.write ('\\include \"paper%d.ly\"\n' % Props.getMudelaFontsize())
- s = fontsize_i2a[Props.getMudelaFontsize()]
- if self.fragment:
- self.file.write("\\paper {" # mudela 1.0.4
- + "\\paper_%s\n linewidth = -1.\\pt;" % s
- + "castingalgorithm = \Wordwrap; indent = 2.\cm; \n}")
- self.file.write("\\score{\n\\notes{")
- else:
- self.file.write ("\paper {"
- + "\\paper_%s\n linewidth = %i.\\pt;" % \
- (s, Props.getLineWidth()) \
- + "castingalgorithm = \Wordwrap; indent = 2.\cm;\n}")
- def close (self):
- if self.fragment:
- self.file.write ('}\\paper { } }\n')
- self.file.close ()
-
- inf = outdir + self.basename + '.ly'
- outf = outdir + self.basename + '.tex'
- if not os.path.isfile(inf):
- status = 1
- else:
- status = os.system ('diff -q %s %s' % (self.temp_filename, inf))
- if status:
- os.rename (self.temp_filename, inf)
- if need_recompile_b(inf, outf):
- out_files.append((self.graphic_type, inf))
- def insert_me_string(self):
- "Returns a string that can be used directly in latex."
- if self.graphic_type == 'tex':
- return ['tex', self.basename]
- elif self.graphic_type == 'eps':
- return ['eps', self.basename]
- else:
- raise SomethingIsSeriouslyBroken
-
-class Tex_output:
- def __init__ (self, name):
- self.output_fn = '%s/%s' % (outdir, name)
- self.__lines = []
- def open_verbatim (self):
- self.__lines.append('\\begin{verbatim}\n')
- def close_verbatim (self):
- self.__lines.append('\\end{verbatim}\n')
- def write (self, s):
- self.__lines.append(s)
- def create_graphics(self):
- s = ''
- g_vec = []
- for line in self.__lines:
- if type(line)==type([]):
- g_vec.append(line)
- for g in g_vec:
- if need_recompile_b(outdir+g[1]+'.ly', outdir+g[1]+'.tex'):
- s = s + ' ' + g[1]+'.ly'
- if s != '':
- os.system('cd %s; lilypond %s' %(outdir, s))
- for g in g_vec:
- if g[0] == 'eps':
- compile('tex %s' % g[1]+'.tex', outdir, g[1]+'.tex', g[1]+'.dvi')
- compile('dvips -E -o %s %s' %(g[1]+'.eps', g[1]+'.dvi'), outdir,
- g[1]+'.dvi', g[1]+'.eps')
- def write_outfile(self):
- outfn = self.output_fn+'.latex'
- sys.stderr.write ('Writing output to `%s\'\n'% outfn)
- file = open(outfn, 'w')
- file.write('% Created by mudela-book\n')
- for line in self.__lines:
- if type(line)==type([]):
- if line[0] == 'tex':
- file.write('\\preMudelaExample\\input %s\n\postMudelaExample '\
-# % (outdir+line[1]+'.tex'))
-
- # TeX applies the prefix of the main source automatically.
- % (line[1]+'.tex'))
- if line[0] == 'eps':
- ps_dim = ps_dimention(outdir+line[1]+'.eps')
- file.write('\\parbox{%ipt}{\includegraphics{%s}}\n' \
-# % (ps_dim[0], outdir+line[1]+'.eps'))
- % (ps_dim[0], line[1]+'.eps'))
-
- else:
- file.write(line)
- file.close()
-class Tex_input:
- def __init__ (self, filename):
- for fn in [filename, filename+'.tex', filename+'.doc']:
- try:
- self.infile = open (fn)
- except:
- continue
- self.filename = fn
- break
- def get_lines (self):
- lines = self.infile.readlines ()
- (retlines, retdeps) = ([],[self.filename])
- for line in lines:
- r_inp = input_re.search (line)
- r_inc = include_re.search (line)
- # Filename rules for \input :
- # input: no .tex ext
- # 1. will search for file with exact that name (tex-input.my will be found)
- # 2. will search for file with .tex ext, (tex-input.my
- # will find tex-input.my.tex)
- # input: with .tex ext
- # 1. will find exact match
-
- # Filename rules for \include :
- # 1. will only find files with name given to \include + .tex ext
- if r_inp:
- t = Tex_input (r_inp.groups()[0])
- ls = t.get_lines ()
- retlines = retlines + ls[0]
- retdeps = retdeps + ls[1]
- elif r_inc:
- t = Tex_input (r_inc.groups()[0]+'.tex')
- ls =t.get_lines ()
- ls[0].insert(0, '\\newpage\n')
- ls[0].append('\\newpage\n')
- retlines = retlines + ls[0]
- retdeps = retdeps + ls[1]
- else:
- retlines.append (line)
- return (retlines, retdeps)
-
-
-class Main_tex_input(Tex_input):
- def __init__ (self, name, outname):
-
- Tex_input.__init__ (self, name) # ugh
- self.outname = outname
- self.chapter = 0
- self.section = 0
- self.fine_count =0
- self.mudtex = Tex_output (self.outname)
- self.mudela = None
- self.deps = []
- self.verbatim = 0
- # set to 'mudela' when we are processing mudela code,
- # both verbatim and graphic-to-be
- self.mode = 'latex'
- def set_sections (self, l):
- if section_re.search (l):
- self.section = self.section + 1
- if chapter_re.search (l):
- self.section = 0
- self.chapter = self.chapter + 1
-
- def gen_basename (self):
- return '%s-%d.%d.%d' % (self.outname,self.chapter,self.section,self.fine_count)
- #return '%s/%s-%d.%d.%d' % (outdir, self.outname,self.chapter,self.section,self.fine_count)
-
- def extract_papersize_from_documentclass(self, line):
- pre = extract_papersize_re.search(line)
- if not pre:
- return None
- return pre.groups()[0]
- def extract_fontsize_from_documentclass(self, line):
- if extract_fontsize1_re.search(line):
- r = extract_fontsize2_re.search(line)
- if r:
- return int(r.groups()[0])
- def do_it(self):
- preMudelaDef = postMudelaDef = 0
- (lines, self.deps) = self.get_lines ()
- for line in lines:
- if documentclass_re.search (line):
- p = self.extract_papersize_from_documentclass (line)
- if p:
- Props.setPapersize(p, 'file')
- f = self.extract_fontsize_from_documentclass (line)
- if f:
- Props.setTexFontsize (f, 'file')
- elif twocolumn_re.search (line):
- Props.setNumColumn (2, 'file')
- elif onecolumn_re.search (line):
- Props.setNumColumn (1, 'file')
- elif preMudelaExample_re.search (line):
- preMudelaDef = 1
- elif postMudelaExample_re.search (line):
- postMudelaDef = 1
- elif begin_document_re.search (line):
- if not preMudelaDef:
- self.mudtex.write ('\\def\\preMudelaExample{}\n')
- if not postMudelaDef:
- self.mudtex.write ('\\def\\postMudelaExample{}\n')
- elif begin_mudela_re.search (line):
- Props.clear_for_new_block()
- if __debug__:
- if self.mode == 'mudela':
- raise AssertionError
- self.mode = 'mudela'
- r = begin_mudela_opts_re.search (line)
- if r:
- o = r.group()[1:][:-1]
- optlist = re.compile('[ ,]*').split(o)
- else:
- optlist = []
- if ('verbatim' in optlist) or (Props.force_verbatim_b):
- self.verbatim = 1
- self.mudtex.open_verbatim ()
- else:
- self.verbatim = 0
- self.mudela = Mudela_output (self.gen_basename ())
-
- elif end_mudela_re.search (line):
- if __debug__:
- if self.mode != 'mudela':
- raise AssertionError
- if self.mudela:
- self.mudela.close ()
- self.mudtex.write (self.mudela.insert_me_string())
- del self.mudela
- self.mudela = None
- self.fine_count = self.fine_count + 1
- else:
- self.mudtex.write (line)
- self.mudtex.close_verbatim ()
- self.mode = 'latex'
- continue
-
- if self.mode == 'mudela' and not self.verbatim:
- self.mudela.write (line)
- else:
- self.mudtex.write (line)
- self.set_sections(line)
- self.mudtex.create_graphics()
- self.mudtex.write_outfile()
- del self.mudtex
-
-
-def help():
- sys.stdout.write("""Usage: mudela-book [options] FILE\n
-Generate hybrid LaTeX input from Latex + mudela
-Options:\n
- -h, --help print this help
- -d, --outdir=DIR directory to put generated files
- -o, --outname=FILE prefix for filenames
- --default-mudela-fontsize=??pt default fontsize for music
- --force-mudela-fontsize=??pt force fontsize for all inline mudela
- --force-verbatim make all mudela verbatim\n"""
- )
- sys.exit (0)
-
-
-def write_deps (fn, out, deps):
- out_fn = outdir + '/' + fn
- out_fn = re.sub ('//', '/', out_fn)
- print 'writing `%s\'\n' % out_fn
-
- f = open (out_fn, 'w')
- f.write ('%s: %s\n'% (outdir + '/' + out + '.dvi',
- reduce (lambda x,y: x + ' '+ y, deps)))
- f.close ()
-
-def identify():
- sys.stderr.write ('This is %s version %s\n' % ('mudela-book', program_version))
-
-def main():
- global outdir
- outname = ''
- try:
- (options, files) = getopt.getopt(
- sys.argv[1:], 'hd:o:', ['outdir=', 'outname=',
- 'default-mudela-fontsize=',
- 'force-mudela-fontsize=',
- 'help', 'dependencies',
- 'force-verbatim'])
- except getopt.error, msg:
- print "error:", msg
- sys.exit(1)
-
- do_deps = 0
- for opt in options:
- o = opt[0]
- a = opt[1]
- if o == '--outname' or o == '-o':
- if len(files) > 1:
- #HACK
- print "Mudela-book is confused by --outname on multiple files"
- sys.exit(1)
- outname = a
- if o == '--outdir' or o == '-d':
- outdir = a
- if o == '--help' or o == '-h':
- help ()
- if o == '--dependencies':
- do_deps = 1
- if o == '--default-mudela-fontsize':
- if not fontsize_pt2i.has_key(a):
- print "Error: illegal fontsize:", a
- print " accepted fontsizes are: 11pt, 13pt, 16pt, 20pt, 26pt"
- sys.exit()
- Props.setMudelaFontsize(fontsize_pt2i[a], 'init')
- if o == '--force-mudela-fontsize':
- if not fontsize_pt2i.has_key(a):
- print "Error: illegal fontsize:", a
- print " accepted fontsizes are: 11pt, 13pt, 16pt, 20pt, 26pt"
- sys.exit()
- Props.force_mudela_fontsize = fontsize_pt2i[a]
- if o == '--force-verbatim':
- Props.force_verbatim_b = 1
-
- if outdir[-1:] != '/':
- outdir = outdir + '/'
-
- if not os.path.isdir(outdir):
- os.system('mkdir %s' % outdir)
-
- for input_filename in files:
- Props.clear_for_new_file()
- if outname:
- my_outname = outname
- else:
- my_outname = os.path.basename(os.path.splitext(input_filename)[0])
- my_depname = my_outname + '.dep'
- inp = Main_tex_input (input_filename, my_outname)
- inp.do_it ()
-
-
- if do_deps:
- write_deps (my_depname, my_outname, inp.deps)
-
-identify()
-Props = Properties()
-main()
+++ /dev/null
-# Documentation/Makefile
-
-depth = ..
-
-
-OUTTXT_FILES = $(OUTYO_FILES:.yo=.txt) $(OUTIN_FILES:.yo=.txt)
-EXTRA_DIST_FILES =
-OUT_DIST_FILES=$(OUTTXT_FILES)
-
-SUBDIRS=topdocs
-
-STEPMAKE_TEMPLATES=documentation install install-out
-
-include $(depth)/make/stepmake.make
-
-default: do-doc
-
-do-doc: $(OUTTXT_FILES)
-
-# ugh
-check-doc-deps: do-doc
- true
-
-doc: do-doc
-
-INSTALLATION_DIR=$(datadir)/Documentation
-INSTALLATION_FILES=$(DIST_FILES)
-
-INSTALLATION_OUT_DIR=$(datadir)/Documentation/out
-INSTALLATION_OUT_FILES=$(OUTTXT_FILES)
-
+++ /dev/null
-article(Automake -- Urgh!)(HWN and JCN)()
-
-sect(Introduction)
-
-Every once in a while, we get comments on our `non-standard' (non GNU
-compliant) configuration/compilation system. In this document, we try
-to explain why we built our own system. We focus on Automake, but of
-course writing complex file(Makefile.in)s without generating them
-automatically is an even more deadly sin in our opinion.
-
-
-sect(What's wrong with Automake?)
-
-We have tried to use Automake and found it to be inadequate for our
-needs for several reasons. On the surface the shortcomings to
-Automake may seem bugs or "not-yet-completed" features. However, file(make)
-itself is broken, and any tool built on top of file(make) is broken as well.
-
-
-sect(Irritations)
-
-We'll start with the superficial irritations first:
-itemize(
-it() there is no intrinsic support for wildcarding; Adding
-support for wildcarding adds yet another layer to a top-heavy system.
-
-This may sound silly, but for a fast moving project, with 1250
-sourcefiles, one does not want to administer a list of filenames by
-hand: files are created, deleted and moved very often, and wildcarding
-prevents that distributions miss files.
-
-
-it() Automake tries to cater for every taste of file(make). But anyone
-who does more than the trivial code(configure; make install) has to
-install Automake and GNU make anyway (for example, you need GCC and
-GNU Make for dependency tracking).
-
-Automake's universal make support is good for tools that have to be
-highly portable, but you have pay in ease of use and speed while
-developing. This means that it is counterproductive to use Automake
-for non-essential programs that are under (heavy) development.
-
-
-it()
-Support for filetypes in built in to Automake, and cannot be added on
-the fly: Automake is very much targeted at standard GNU packages that
-are written in C (or C++) and come with info-pages. If you want to
-add dependencies from TeX() or METAFONT files you are out of luck.
-Ditto if you have weird file types (.pod), weird programming
-languages, etc.
-
-There are as many file types as there are languages and compilers.
-Extending Automake to support all these languages is error-prone, and
-creates nasty version dependencies between an Automake-using package
-and Automake itself. A package should be able to supply its own
-specific rules and targets.
-
-it() Dependency handling is unreliable in our experience. On
-several occasions we had unexplainable errors, that went away after
-doing a code(make distclean), and recompile.
-
-it() It is slower, much slower than a tailored solution. This
-diffence in speed can be as large as 800%. (On JCNs machine a
-code(make dist) takes 17 minutes in stead of 2) for every distribution
-made; this constitutes 45 minutes of irritation on an average hacking-night.
-
-it() For a large project, a specialised file(Makefile) system costs
-relatively little extra effort. The extra effort pays itself back in
-speed and control.
-
-it() The file(Makefile)s, file(Makefile.in)s, and extensions
-constitute a huge amount of state. We found it hard to reproduce bugs
-in Automake (Strictly spoken they aren't bugs, as we haven't diagnosed
-because we couldn't reproduce them.) )
-
-sect(Fundamental problems)
-
-Many of the fundamental problems can be traced back to flaws in make:
-
-itemize(
-it() make is not standardised. The only decent implementation is
-GNU make, and GNU make is not widespread enough to require GNU make for
-compiling GNU tools.
-
-it() make does not have enough meta-ness: one cannot manipulate
-dependencies and rules in make: they cannot be put in variables,
-mapped at lists, etc.
-
-(In our tailor made compilation system, we worked around this
-non-feature by using generic include files as a stopgap function
-call.)
-
-
-
-it() code(VPATH) is a broken concept: programs should not try to be
-intelligent on their own; being intelligent is something the
-programmer should do. make should do exactly as it is told, and make
-should enable easy formulation of these commands.
-)
-
-Automake tries to solve these problems by building on top of this
-broken tool: an extra layer of complexity is added, with
-self-modifying Makefiles, and different Makefile versions for
-maintainer and user.
-
-
-sect(Conclusions)
-
-We could be called `cheap' for complaining about the above points,
-while not even filing decent bugreports. The reality is that we
-ourselves are busy and that we don't find it amusing to hunt for and
-fix bugs in a fix (Automake) for a broken tool (make).
-
-It should also be emphasised that we still think that Automake is a
-good tool: it is excellent for small projects, and reasonable for big
-projects that are fully "standard." However, for LilyPond, with its
-many sourcefiles and many different filetypes we found it unwieldy.
-
-We hope that some day a better replacement for make comes along, so
-that the gruesomeness of make and friends may die in oblivion. (*)
-
-(*) I personally would like to enter a Makefile as functional program,
-whose execution caches function results on the disk as files. But I
-shan't bother you further with my vaporware thoughts..
+++ /dev/null
-verb(
- doos/ # gnu/windows32 build and binary releases
- harmonia -> harmonia-x.y.z
- harmonia-x.y.z/
- lilypond -> lilypond-x.y.z # symlink to development directory
- lilypond-x.y.z/ # current development
- patches/ # patches between different releases
- RedHat/BUILD # RedHat build and binary releases
- RedHat/RPMS
- RedHat/SPECS
- releases/ # .tar.gz releases
- test/ # tarballs and diffs from current version
- yodl -> yodl-1.30.17
- yodl-1.30.17
-)
-with prefix file($HOME/usr/src)
-and (for building rpms only) in file($HOME/.rpmrc):
-verb(
- topdir: /home/fred/usr/src/RedHat
-)
+++ /dev/null
-nsect(NAME)
-
-AUTHORS - who did what on StepMake?
-
-nsect(DESCRIPTION)
-
-This file lists authors of StepMake, and what they did.
-
-nsect(AUTHORS)
-itemize(
-it()nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl),
- lurl(http://www.cs.uu.nl/people/hanwen)
- nl()
- Main author.
-
-it()nemail(Jan Nieuwenhuizen)(janneke@gnu.org),
- lurl(http://www.xs4all.nl/~jantien)
- nl()
- Main author.
-it()nemail(Jeffrey B. Reed)(daboys@austin.rr.com),
- Windows-nt fixes.
-)
-
+++ /dev/null
-StepMake is a drop-in package that takes care of generic Makefile and
-packaging/distribution issues. It enables you to write only the simplest of
-Makefile snippets, while providing a series powerful make targets. Features
-include speed, wildcarding, out/ dir build, stateless Makefiles and package
-clustering. It includes some handy scripts for making (package-)diffs and
-patches, making binary distributions etc.
+++ /dev/null
-# Documentation/topdocs/Makefile
-
-depth = ../..
-
-SUBDIRS=
-BLURBS=BLURB #COPERTINA FLAPTEKST
-AT_FILES = $(BLURBS) #
-at-dir = $(doc-dir)/
-at-ext = .in
-BLURBS=BLURB COPERTINA FLAPTEKST
-OUT_DIST_FILES=$(OUTTXT_FILES)
-
-STEPMAKE_TEMPLATES=documentation yolily-topdoc install install-out
-
-include $(depth)/make/stepmake.make
-
-INSTALLATION_DIR=$(datadir)/Documentation/topdocs
-INSTALLATION_FILES=$(DIST_FILES)
-POST_INSTALL=-mkdir $(INSTALLATION_DIR)/out
-
-INSTALLATION_OUT_DIR=$(datadir)/Documentation/topdocs/out
-INSTALLATION_OUT_FILES=$(OUTTXT_FILES)
-
+++ /dev/null
-nsect(NAME)
-
-INSTALL - installing StepMake
-
-nsect(DESCRIPTION)
-
-This page documents installation and usage of StepMake
-
-nsect(ABSTRACT)
-
-verbinclude(BLURB.in)
-
-To use StepMake with your package, you do something remotely like:
-verb(
- tar xzf releases/stepmake-0.1.23
- cd package-x.x.x/ # package to be StepMake-ised
- ./../stepmake-0.1.23/bin/stepmakeise.sh
-)
-You'll have to customize at least the files:
-verb(
- ./VERSION .
- ./configure.in
-)
-to your package's needs. You might want to take a look at:
-verb(
- ./make/Toplevel.make.in
- ./config.hh.in
- ./config.make.in
-)
-
-Also, you should put a Makefile in every subdirectory of your
-package. These makefiles generally are quite simple, e.g. this
-is a the makefile for an include directory of LilyPond:
-verb(
- # lily/include/Makefile
-
- depth = ../..
- include $(depth)/make/Stepmake.make
-)
-
-it will identify all code(.h, .hh, ...) files and take care of distributing
-them.
-
-There's a file(make/Template.make) that you can use as an example.
-See also the Makefiles in the LilyPond or Yodl package.
-
-
-Once included in your package, StepMake (or in fact, any
-StepMake-ised package) behaves as a normal subdirectory;
-make commands such as 'make dist' recurse into the stepmake tree
-(For a list of available targets, type code(make help) after
-configuring).
-Stepmake (and any changes made) will be distributed with the main
-pacakage. However, StepMake doesn't lose its independency, change
-to the stepmake directory, and it'll behave as a main package.
-You shouldn't version directory names of subpackages, otherwise
-you'll see that package twice in each patch when you upgrade.
-
-nsect(PREREQUISITES)
-
-To use StepMake with a package you need:
-
-itemize(
-it()A GNU system: StepMake is known to work on these GNU systems: Linux
- (PPC, intel), FreeBSD, AIX, NeXTStep, IRIX, Digital Unix and Solaris.
- If you have the Cygnus WINDOWS32 port of the GNU utils, it will even
- work in Windows NT/95, but we don't promise to support it.
-it()GNU make
-it()GNU autoconf
-)
-
-nsect(RECOMMENDED)
-
-Although not strictly necessary, these are recommended to have.
-
-itemize(
-it()Python
-it()Yodl. All documentation will be in Yodl. (1.22.jcn3)
-it()GNU find
-)
-
-nsect(INTERNALS)
-COMMENT(Hmm, started-out as an email...)
-
-Over time, we put a lot of effort in the configure, make, distribute
-system (CMDS) for LilyPond. Some months ago, we realised it was not
-standard GNU --- we require GNU make for building, and Python for extra
-scripting. In an effort to be more GNU, we tried automake, but after two
-weeks we realised the costs were too high for us and we reverted to our
-own system (see file(automake.urgh)). Not long after that i was confronted
-with two other packages that lacked a decent CMDS. I realised that Lily's
-would be perfect, it's modular and easy. The only problem was to make a
-clean cut between generic and Lily specific stuff. The result was
-StepMake: a bunch of generic makefiles, found in:
-verb(
- stepmake/stepmake/*.make
-)
-eneric helper scripts:
-verb(
- stepmake/bin/*.sh
- stepmake/bin/*.py
-)
-and modular configure functions:
-verb(
- stepmake/configure.in
- stepmake/aclocal.m4
- stepmake/config.hh.in
- stepmake/config.make.in
-)
-
-Of course, every package has its own configure- and make peculiarities.
-The best way to create the configure scripts is to copy them from
-nop(stepmake)footnote(Actually, stepmake/bin/stepmakeise.sh will do
-that for you.) into you package's toplevel directory. For most
-packages, you'll only have to comment in/out some functions in
-file(configure.in).
-
-Package specific makefiles go in:
-verb(
- make/Targets.make
- make/Rulese.make
- make/Substitute.make
-)
-and are included by the generic StepMake makefiles.
-
-nsect(MAINTAINING)
-
-If you want to make and manage (binary) distributions, create and apply
-patches, you'll need some framework that's outside of the package's
-sourcetree.
-For a number of simple maintenance tasks, StepMake will therefore assume
-the following directory structure:
-
-includefile(../layout.yo)
-
-Check and update the layout with the command:
-verb(
- ./stepmake/bin/stepdirs.sh
-)
-
-nsect(SEE ALSO)
-
-code(../PATCHES.txt)
-
-nsect(CONFIGURING)
-
-Stepmake comes with a number of precooked configure functions for
-general needs, such as AC_STEPMAKE_COMPILE for simple C development
-and AC_STEPMAKE_CXX for C++.
-
-See configure.in and comment in/out the functions that your package
-needs. For specific needs, you can write your own autoconf code,
-see code(info autoconf).
-
-nsect(AUTHORS)
-
-nemail(Jan Nieuwenhuizen)(janneke@gnu.org)
-
-nemail(Han-Wen Nienhuys)(hanwen@cs.uu.nl)
-
-Have fun!
-
+++ /dev/null
-pl 80
- - use mgsmerge iso tupdate
-
-pl 79
- - empty sed script fix for aix
-
-pl 78
- - yodl mode, mp fixes
-
-pl 77
- - mfmode
-
-pl 76
- - bfs: shells, scripts
-
-pl 75
- - bfs: release
-
-pl 74
- - avoid buggy /bin/sh on hp-ux
- - bf: make/stepmake.make
- - simple prolog support
-
-pl 73
- - bf: invoke sed only once
-
-pl 72
- - bf: mfplain dependency
- - inimf, inimf checking (sigh)
-
-pl 71
- - bf: c-tags
- - yodl: groff, ditroff
-
-pl 70
- - GUILE config fixes (AF)
-
-pl 69
- - package_depth detection fix
-
-pl 68
- - support for install-libraries
-
-pl 66
- - check for tbl and gmake
-
-pl 65
- - unix style pathsep/dirsep for cygwin
-
-pl 64
- - gcc-2.8/egcs
-
-pl 63
- - CFLAGS from yodl debian patch
-
-pl 62
- - fixed dist from subdirs
- - junked stepmake/aclocal.m4 (again?)
- - resurrected po stuff
-
-pl 61
- - bf: package-diff
-
-pl 60
- - small fixes.
-
-pl 59
- - bf: package-diff (remove missing automatic)
- - install templates, (urg) INSTALL*1,2 INSTALL_OUT*1,2
-
-pl 58
- - distribute formatted txt files: no yodl needed for operation!
- - guile 1.2 and 1.3 support
-
-pl 57
- - yodl first build script fixes
- - uninstall fixes, but, urg, still have to uninstall twice
- to get rid of all subdirs
- - installed stepmake
- * install not required
- * only installs on explicit make install from toplevel stepdir
- * rather urg, 'make dist' needs absolute distdir!
-
-pl 56
- - crude metapost stuff
-
-pl 55
- - table-to-html stuff moved .
-
-pl 54
- - && for TeX
-
-pl 53
- - moved TeX stuff into tex template
-
-pl 52
- - striproff
- - reeable $(PACKAGE)_LIBES,_INCLUDES
- - metafont rules
- - GTK+, --, -draw config stuff
-
-pl 51
- - bumped version nr
-
-pl 50
- - bf's: PATHSEP
- - png
-
-pl 49
- - use yodl2ms and striproff for txt conversion
- - bf: chmod fail
-
-pl 48
- - bumped version for yodl after various (lily pl7) changes
-
-pl 47
- - bf: patch in website after 'make release'
- - windows ln -> cp
- - bf: texinfo build
-
-pl 46
- - bf: versioning typo: topleveL_MAJOR
- - bf: reincluded optional STATE-VECTOR
-pl 45
- - Foo_rules.make -> foo-rules.make
-
-pl 44
- - split: Toplevel.make, debian/Makefile, Documentation/topdocs/Makefile
-
-pl 43
- - grand split up in targets/rules/variables. The vars should be before rules!!
-pl 42
- - fake-msgfmt.sh; urg copied from fake-yodl
-
-pl 41
- - standard naming: _FILES
- - use install-sh
- - junked most check-X-deps
- - standard naming: dir/out/library.a
- - split C++ / C stuff in separate files. Moved out of default stuff
- - automake.yo updates
- - fake-yodl.sh
-
-pl 40
- - bf's: texinfo
- - bf's: package-zip.sh for bash-2.0
- - typo package-diff
-
-pl 39
- - disabled toplevel index
-
-pl 38
- - bf's: topweb, Documentation
- - bf: ls-latex
-
-pl 37
- - bf's: add-html-footer (ok, i've been reading /.)
-
-pl 36.hwn1
- - Metafont.make
- - use := assignment for shell & wildcard stuff
-
-pl 36
- - bf: Executable.make install
-
-pl 35
- - bf: Po_rules
- - grand foreach hack (HWN)
-
-pl 34
- - stepmake/*shared.make
-
-pl 33
- - make dist fix
- - yodl/lily website fixes
-
-pl 32
- - DEPTH: enable fixing of 'yodl using yodl'
- - bf's: package-diff: --dir-*
-
-pl 31.hwn1
- - bf ls-latex.py; added format
-
-pl 31
- - fixed make-flags
- - fixup package-diff and added to-dir, from-dir
-
-pl 30.hwn2
- -
-
-pl 30.hwn1
- - doc++ target
- - make -> $(MAKE)
-
-pl 30
- - add-html-footer: html/body/title
-
-pl 29.hwn1
- - automake.urgh -> automake.yo
-
-pl 29
- - counter fix
-
-pl 28
- - mini fix voor soladeris (HWN)
- - add-html-footer fixes
- - dropped pl
-
-pl 27
- - irix fixes(?) (HWN)
-
-pl 26.jcn3
- - update.py: try at stupid advice
- - bf: ls-latex .yo author
- - bf: Excutable.make install
-
-pl 26.jcn2
- - no changes
-
-pl 26.hwn1
- - no changes; just testin' make update
-
-pl 26.jcn1
- - no changes
-
-pl 26
- - make apply
- - package-to.diff.gz
- - package-from-to.diff.gz with state-vector
- - state vector
-
-pl 25
- - bf: add-html-footer.py: version_str iso tuple
- - typo: Executable.make
- - for 2latex: yodl2latex of yodl-1.30.0.pre9
- - package depth 'detected' by configure (kinda ugh)
- - fixes (HWN)
-
-pl 24
- - binary releases:
- * make deb
- * dpkg 1.4.0.23.2
- * debhelper 0.96
- * /usr/bin/db_*: remove -p from install options (urg)
- * make rpm
- * make zip
- - debian fixes
- - SEXECUTABLES / EXECUTABLES (JBR)
- - fixed package-zip.sh (again?)
- - bf's: make zip
- - some doco
- - bf: STRIPFILES
- - rpm from tarball in $(depth)/$(outdir)
- - dropped lilypython, pythonblurb
- - bf's: flower.py/packagepython.py/package-diff.py
-
-
-pl 23.hwn2
- - add mailaddress to package-diff, beautifications
-
-pl 23.hwn1
- - release.py: check make dist retval
- - revamped rpm stuff.
- - bf abs-step-bindir
-
-
-pl 23
- - relaxed 'error' to '-echo' for non-vital utilities
- - table-to-html.py
- - bin/stepdirs.sh
- - bin/stepmakeise.sh
- - --package-ised
- - windows-nt fixes (JBR)
-
-pl 22
- - new zip stuff
-
-pl 21
- - packagepythonified add-html-footer, ls-latex
- - packagepython (dankje lieverd)
- - LD
- - bf: don't diff .pyc
- - yodl2 -> YODL2
- - AC_STEPMAKE_YODL
- - vars: GCC/TROFF/LD
-
-pl 20
- - bf: ls-latex: .yo author + title
- - htmldoc fix
- - ls-latex
- - add-html-footer
- - po stuff
- - latex + bibtex
- - latex2yodl fixes
-
-pl 19
- - add htmlfooter to all yodl chapter files
- - .latex for latex files
- - tex2html -> latex2html.sh
-
-pl 18
- - package-zet.sh
- - cleaned-out configure -> aclocal.m4
- - (step)make targets:
- * diff
- * help
- * rpm
- * zip
- - tex2yodl.pl helper
- - patches are now called $package-$TOPLEVEL_VERSION.diff
- - fixed @FILE@ and @VAR@ substitute
- - bf: DO_CXX_COMPILE
-
-pl 17
- - C rules :-)
- - bf's Template.make
-
-pl 16
- - more lily macros -> generic stepmake
- - dropped POD configuration
- - used it
- - pod2yodl: one time conversion helper
-
-pl 15
- - fixes: texi2man
-
-pl 14
- - text2html
-
-pl 13
- - texinfo support
- - removed mudela rules
-
-pl 12
- - irix patch
-
-pl 11
- - 'urg comment' by wendy
- - python fixes
-
-pl 10
- - more from lily
- - sed-stuff
-
-pl 9
- - configure fix for irix tr
- - bf: Install_*.make
- - bf: PACKAGE_ ROOTDIR
-
-pl 8
- - some python stuff from lily
-
-pl 7
- - PACKAGE_NAME
- - BLURB
- - INSTALL doco
- - Documentation/
-
-pl 6
- - bf: include makedir/Rules.make too
- - Documentation/automake.urgh
-
-pl 5
- - allow chained make-dist
-
-pl 4
- - DOTTEXT->.txt
-
-pl 3
- - included more Lily makefiles
-
-pl 2
- - dropped $(package) in makefile names
- - moved stepmake makes to stepmake/
-
-pl 1
- - preparing for verbatim include
-
-pl 0
- - shared between lilypond-0.1.69 lilyx-0.1.0
projects / lilypond.git / commitdiff