From: Han-Wen Nienhuys Date: Wed, 20 Oct 1999 23:57:50 +0000 (+0200) Subject: release: 1.2.16 X-Git-Tag: release/1.2.16 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=70616862ee425830c3c6bb63f2eec197fef9bbd7;p=lilypond.git release: 1.2.16 --- diff --git a/CHANGES b/CHANGES index 3c38ef3ad1..2fc2e6b428 100644 --- a/CHANGES +++ b/CHANGES @@ -1,19 +1,32 @@ -pl 15.jcn4 - - direct #... to scm parser (Tanks to Gary Houston) +pl 15.hwn1 + - reverted MIDI unfold patches. + - bf: cross staff beam, cross staff slur (2x) + - doco updates: + * metadoc/ -> programmer/ , + * FAQ + * hacking + * index with logo pl 15.jcn3 - - bf: smob fix? + - bf: smob fix - mutopia/doc target 'local-web': shorthand for 'CONFIGSUFFIX=www local-WWW' +pl 15.lu2 + - bf: close comments in website footer + - error messages for release didn't make it into .lu1? pl 15.jcn2 - small website fixes - pl 15.jcn1 - bfs: initialise members of Column-x-positions and Break_node - bf: Documentation/misc: don't include backups - bf: .gdbinit +pl 15.lu1 + - error messages for failing diff/release + - \property noStemExtend: don't extend normal or beamed stems to + middle staff line: input/test/no-stem-extend.fly +****** pl 15 (Oct 18) 14.jcn1 diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index 3834700846..b3fda3a821 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -1,7 +1,7 @@ depth = .. NAME = documentation -SUBDIRS= user metadoc bibliography pictures topdocs ntweb misc +SUBDIRS= user programmer bibliography pictures topdocs ntweb misc STEPMAKE_TEMPLATES=documentation texinfo README_TOP_FILES=NEWS DEDICATION CHANGES TODO diff --git a/Documentation/bibliography/GNUmakefile b/Documentation/bibliography/GNUmakefile index a7862db9ae..ca0c7ae4a4 100644 --- a/Documentation/bibliography/GNUmakefile +++ b/Documentation/bibliography/GNUmakefile @@ -33,7 +33,7 @@ $(outdir)/%.bib: %.bib # ignore result since bib2html is nonstandard. Errors would halt the RPM build.j $(outdir)/%.html: %.bib -bib2html $< $@ - $(footify) $@ +# $(footify) $@ localclean: rm -f fonts.aux fonts.log feta*.tfm feta*.*pk diff --git a/Documentation/faq.texi b/Documentation/faq.texi index da64d5cc52..b8dbb30787 100644 --- a/Documentation/faq.texi +++ b/Documentation/faq.texi @@ -77,7 +77,7 @@ yourself: @subsubsection 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 +[This only applies if you don't do @code{make install}, and run out of the source directory] I have a directory which contains all our development projects @@ -100,16 +100,13 @@ which looks like @file{/usr/} @end example - - - -~/usr/src/bin is in the PATH, and contains symbolic links to the -compiled executables. +@file{~/usr/src/bin/} is in the variable PATH, and contains symbolic +links to the compiled executables. @subsubsection 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 +you have an rpm it is in @file{/usr/doc/lilypond-X/}. You have to install it yourself. @subsubsection How do I create the @file{.tfm} files? @@ -124,12 +121,12 @@ be used by LilyPond, not by any other programs. @subsubsection 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. +LilyPond development is moving quite fast, documentation will often lag +a bit behind. We must always make a choice between writing more +documentation, writing HTML, 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. +If you think you can make a correction, or devised a solution that +should be documented, please write it up, and us a diff. @node Language- mudela, Do you support -, Documentation, FAQ - GNU LilyPond FAQs @section Language: mudela @@ -195,20 +192,20 @@ notation. We would welcome anyone who could give this a try. @subsubsection Do you support TAB notation? -No. The same as for the previous subsubsection 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.) +No. The same as for the previous subsubsection goes. + @subsubsection 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. +Yes. At this time you can choose between 11, 13, 16, 19, 20, 23 and 20 +pt staff-size. Use the @code{staffLineLeading} property for setting the +size of the staff, and @code{fontSize} for setting the size of the +glyphs. @subsubsection Do you support Gregorian chant notation? -No. Go ahead. +No. + @subsubsection Do you support grace notes? @@ -318,38 +315,34 @@ to get a bit less frivolous tagging. @subsubsection 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. +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. @subsubsection Can I join in on LilyPond development? How do I do this? -LilyPond development is open for anyone who wants to join. We do -frequent releases, you are welcome to send in a patch or do suggestions. -Join the gnu-music-discuss mailing list to participate. +Yes, we do frequent releases, you are welcome to send in a patch or do +suggestions. Join the list @email{gnu-music-discuss@@gnu.org} to +participate. -@subsubsection I want to implement XXXX! Should I do this? - -Yes. - -But since 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 - @subsubsection 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. +LilyPond currently has no graphical interface. We (LilyPond authors) +don't feel the need to write a GUI, but several others do: Matthew Hiller has extended Midiscore and Koobase to handle mudela. -Check out @uref{http://zoo.cs.yale.edu/~meh25/}. +Check out @uref{http://zoo.cs.yale.edu/~meh25/}. He is now working on +`Denemo', a GTK based notation program (which is still being developed). -If you want to work on this, please send e-mail to the mailing list -@email{gnu-music-discuss@@gnu.org}. +Federico Mena-Quintero and Elliot Lee of RedHat Advanced Development +labs have plans to write a GNOME based Music notation program. However, +there is no code, only plans. + +Chris Cannam is working a rewrite of Rosegarden. The new design should +be more modular, and could conceivably be used to output +mudela. However, the not much seems to have happened the past year. See +@uref{http://www.all-day-breakfast.com/rosegarden/development.html}. @subsubsection I want to implement XXXX! How should I do this? @@ -360,32 +353,20 @@ Your best bet of getting us to include code, is to present it as a Please use the diff command to generate a patch, and don't send complete files, even if the diff is larger than the whole file. -Don't forget to put your name and e-mail address -in the @file{AUTHORS.pod} file, or you won't get credits :-] +Don't forget to put your name and e-mail address in the file +@file{Documentation/topdocs/AUTHORS.texi}, or you won't get credits +:-) @subsubsection 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 +programs (autoconf, automake, libtool) and found to be inadequate for +our needs. @subsubsection gdb crashes when I debug! -Upgrade to 4.17. - -@subsubsection 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 @emph{lot} of trouble. +Upgrade/downgrade to 4.17. @node Running, Copyright, Development, FAQ - GNU LilyPond FAQs @section Running @@ -466,24 +447,6 @@ output, use TeX and @code{dvips}. The beams and slurs are done in PostScript. XDvi doesn't show PostScript in the magnifying glass. Complain to the XDvi maintainers. -@subsubsection I don't get midi-output, even if I use @strong{-m}! - -Your \score should include a \midi block, eg. -@example - - \score @{ - \melodic @{ c4 c g g @} - \paper @{@} - \midi @{ - output = "myfile.midi"; - \tempo 4=70; - @} - @} - -@end example - -The @strong{-m} option was added to LilyPond to suppress paper output, -because processing the \paper block is so slow. @subsubsection A lot of musical stuff doesn't make it to the MIDI file, eg. dynamics, articulation, etc. diff --git a/Documentation/footer.html.in b/Documentation/footer.html.in index 4b99be2c58..50bcaf5b2d 100644 --- a/Documentation/footer.html.in +++ b/Documentation/footer.html.in @@ -11,7 +11,7 @@ footer substitutions: * ENV:WEBMASTER, * ENV:WEBMASTER -> +-->
Go back to index of LilyPond. @@ -23,7 +23,7 @@ Please send GNU LilyPond questions and comments to gnu-music-discuss@gnu.org.

- Please send comments on these web pages to %s diff --git a/Documentation/index.texi b/Documentation/index.texi index 6f479604f1..0187a0a409 100644 --- a/Documentation/index.texi +++ b/Documentation/index.texi @@ -21,7 +21,7 @@ @item @uref{faq.html,Frequently asked questions}, with answers @item @uref{programs.html,`Manual pages'} @item @uref{../user/out-www/index.html,User documentation} -@item @uref{../metadoc/out-www/index.html,Hacker documentation} +@item @uref{../programmer/out-www/index.html,Programmer's documentation} @item @uref{../bibliography/out-www/index.html,Bibliography} @item @uref{../misc/out-www/index.html,Miscellaneous texts} @end itemize @@ -44,7 +44,8 @@ @unnumberedsubsec Logo: @itemize @item @uref{../pictures/out-www/lelieblond.png, logo} in large size -@item @uref{../pictures/out-www/lelie_logo.png, logo} in medium size +@item @uref{../pictures/out-www/lelie-logo.png, logo} in medium size +@item @uref{../pictures/out-www/lelie-icon.png, logo} in small size @end itemize @bye diff --git a/Documentation/metadoc/GNUmakefile b/Documentation/metadoc/GNUmakefile deleted file mode 100644 index 25b42eea53..0000000000 --- a/Documentation/metadoc/GNUmakefile +++ /dev/null @@ -1,36 +0,0 @@ -# Documentation/tex/Makefile - -depth=../.. - -TEX_FILES = $(wildcard *.tex) -DOC_FILES = $(wildcard *.doc) -DVI_FILES = $(addprefix $(outdir)/,$(DOC_FILES:.doc=.dvi) $(TELY_FILES:.tely=.dvi)) - -OUTTEX_FILES = $(addprefix $(outdir)/, $(TEX_FILES)) -OUTDOC_FILES = $(addprefix $(outdir)/, $(DOC_FILES)) - -EXTRA_DIST_FILES= $(DOC_FILES) $(TEX_FILES) $(wildcard *.sty) -HTML_FILES = $(addprefix $(outdir)/, $(TEXI_FILES:.texi=.html) $(TELY_FILES:.tely=.html)) -PS_FILES = $(DVI_FILES:.dvi=.ps) - -STEPMAKE_TEMPLATES=tex documentation texinfo -LOCALSTEPMAKE_TEMPLATES=lilypond mudela - -export BIBINPUTS:=$(shell pwd)//$(PATHSEP)$(BIBINPUTS) -include $(depth)/make/stepmake.make - -dvi: $(DVI_FILES) - -ps: $(PS_FILES) - -# urg -default: - - -localclean: - rm -f fonts.aux fonts.log feta*.tfm feta*.*pk - -local-WWW: $(HTML_FILES) - $(PYTHON) $(step-bindir)/ls-latex.py --title 'Hacker documentation' \ - $(DOC_FILES) $(TEXI_FILES) $(TELY_FILES) \ - | sed "s!$(outdir)/!!g" > $(outdir)/index.html diff --git a/Documentation/metadoc/feta20.sty b/Documentation/metadoc/feta20.sty deleted file mode 100644 index 0dbfcf90cc..0000000000 --- a/Documentation/metadoc/feta20.sty +++ /dev/null @@ -1,146 +0,0 @@ -% Creator: mf-to-table.py version 0.7 -% Automatically generated on -% Do not edit -% input from out/feta20.log -% name -% rests -\fetdef\wholerest{0} -\fetdef\halfrest{1} -\fetdef\outsidewholerest{2} -\fetdef\outsidehalfrest{3} -\fetdef\breverest{4} -\fetdef\longarest{5} -\fetdef\multirest{6} -\fetdef\quartrest{7} -\fetdef\eighthrest{8} -\fetdef\sixteenthrest{9} -\fetdef\thirtysecondrest{10} -\fetdef\sixtyfourthrest{11} -\fetdef\hundredtwentyeighthrest{12} - -% accidentals -\fetdef\sharp{13} -\fetdef\natural{14} -\fetdef\flat{15} -\fetdef\flatflat{16} -\fetdef\sharpsharp{17} -\fetdef\rightparen{18} -\fetdef\leftparen{19} - -% dots -\fetdef\dot{20} -\fetdef\repeatcolon{21} - -% balls -\fetdef\brevisball{22} -\fetdef\brevisledger{23} -\fetdef\longaball{24} -\fetdef\longaledger{25} -\fetdef\wholeball{26} -\fetdef\wholeledger{27} -\fetdef\halfball{28} -\fetdef\halfledger{29} -\fetdef\quartball{30} -\fetdef\quartledger{31} - -% scripts -\fetdef\ufermata{32} -\fetdef\dfermata{33} -\fetdef\thumb{34} -\fetdef\sforzatoaccent{35} -\fetdef\staccato{36} -\fetdef\ustaccatissimo{37} -\fetdef\dstaccatissimo{38} -\fetdef\tenuto{39} -\fetdef\umarcato{40} -\fetdef\dmarcato{41} -\fetdef\ouvert{42} -\fetdef\plusstop{43} -\fetdef\upbow{44} -\fetdef\downbow{45} -\fetdef\reverseturn{46} -\fetdef\turn{47} -\fetdef\trill{48} -\fetdef\upedalheel{49} -\fetdef\dpedalheel{50} -\fetdef\upedaltoe{51} -\fetdef\dpedaltoe{52} -\fetdef\flageolet{53} -\fetdef\trilelement{54} -\fetdef\prall{55} -\fetdef\mordent{56} -\fetdef\prallprall{57} -\fetdef\prallmordent{58} -\fetdef\upprall{59} -\fetdef\downprall{60} -\fetdef\accDiscant{61} -\fetdef\accDiscantF{62} -\fetdef\accDiscantEh{63} -\fetdef\accDiscantE{64} -\fetdef\accDiscantFE{65} -\fetdef\accDiscantFEh{66} -\fetdef\accDiscantEE{67} -\fetdef\accDiscantFEE{68} -\fetdef\accDiscantEEE{69} -\fetdef\accDiscantFEEE{70} -\fetdef\accDiscantS{71} -\fetdef\accDiscantFS{72} -\fetdef\accDiscantES{73} -\fetdef\accDiscantEhS{74} -\fetdef\accDiscantFES{75} -\fetdef\accDiscantFEhS{76} -\fetdef\accDiscantEES{77} -\fetdef\accDiscantFEES{78} -\fetdef\accDiscantEEES{79} -\fetdef\accDiscantFEEES{80} -\fetdef\accDiscantSS{81} -\fetdef\accDiscantESS{82} -\fetdef\accDiscantEESS{83} -\fetdef\accDiscantEEESS{84} -\fetdef\accFreebass{85} -\fetdef\accFreebassF{86} -\fetdef\accFreebassE{87} -\fetdef\accFreebassFE{88} -\fetdef\accStdbass{89} -\fetdef\accStdbassM{90} -\fetdef\accStdbassBp{91} -\fetdef\accStdbassT{92} -\fetdef\accStdbassTp{93} -\fetdef\accBayanbass{94} -\fetdef\accBayanbassT{95} -\fetdef\accBayanbassE{96} -\fetdef\accBayanbassTE{97} -\fetdef\accBayanbassEE{98} -\fetdef\accBayanbassTEE{99} -\fetdef\accSB{100} -\fetdef\accBB{101} -\fetdef\accOldEE{102} -\fetdef\accOldEES{103} - -% flags -\fetdef\eighthflag{104} -\fetdef\sixteenthflag{105} -\fetdef\thirtysecondflag{106} -\fetdef\sixtyfourthflag{107} -\fetdef\deighthflag{108} -\fetdef\dsixteenthflag{109} -\fetdef\dthirtysecondflag{110} -\fetdef\dsixtyfourthflag{111} - -% clefs -\fetdef\altoclef{112} -\fetdef\caltoclef{113} -\fetdef\bassclef{114} -\fetdef\cbassclef{115} -\fetdef\trebleclef{116} -\fetdef\ctrebleclef{117} - -% timesig -\fetdef\fourfourmeter{118} -\fetdef\allabreve{119} -\fetdef\oldfourfourmeter{120} -\fetdef\oldallabreve{121} -\fetdef\oldthreetwometer{122} -\fetdef\oldsixfourmeter{123} -\fetdef\oldninefourmeter{124} - diff --git a/Documentation/metadoc/fonts.doc b/Documentation/metadoc/fonts.doc deleted file mode 100644 index 287dde49b1..0000000000 --- a/Documentation/metadoc/fonts.doc +++ /dev/null @@ -1,330 +0,0 @@ - - % -*-LaTeX-*- - -\documentclass{article} -\def\kdots{,\ldots,} -\title{Not the Font-En-Tja font} -\author{HWN \& JCN} -\def\preMudelaExample{} -\def\postMudelaExample{} -\begin{document} -\maketitle - - -\section{Introduction} - -This document are some design notes of the Feta font, and other -symbols related to LilyPond. Feta (not an abbreviation of -Font-En-Tja) is a font of music symbols. All MetaFont sources are -original. The symbols are modelled after various editions of music, -notably \begin{itemize} \item B\"arenreiter \item Hofmeister \item -Breitkopf \item Durand \& C'ie \end{itemize} - -The best references on Music engraving are Wanske\cite{wanske} and -Ross\cite{ross} some of their insights were used. Although it is a -matter of taste, I'd say that B\"arenreiter has the finest typography -of all. - - -\section{Bezier curves for slurs} - -Objective: slurs in music are curved objects designating that notes -should fluently bound. They are drawn as smooth curves, with their -center thicker and the endings tapered. - -There are some variants: the simplest slur shape only has the width as -parameter. Then we give some suggestions for tuning the shapes. The -simple slur algorithm is used for drawing ties as well. - - - -\subsection{Simple slurs} - -Long slurs are flat, whereas short slurs look like small circle arcs. -Details are given in Wanske\cite{ross} and Ross\cite{wanske}. The -shape of a slur can be given as a Bezier curve with four control -points: - -\begin{eqnarray*} - B(t) &=& (1-t)^3c_1 +3(1-t)^2tc_2 + 3(1-t)t^2c_3 + t^3c_4. -\end{eqnarray*} - -We will assume that the slur connects two notes of the same -pitch. Different slurs can be created by rotating the derived shape. -We will also assume that the slur has a vertical axis of symmetry -through its center. The left point will be the origin. So we have -the following equations for the control points $c_1\kdots c_4$. - -\begin{eqnarray*} -c_1&=& (0,0)\\ -c_2&=& (i, h)\\ -c_3&=& (b-i, h)\\ -c_4&=& (b, 0) -\end{eqnarray*} - -The quantity $b$ is given, it is the width of the slur. The -conditions on the shape of the slur for small and large $b$ transform -to -\begin{eqnarray*} - h \to h_{\infty} , &&\quad b \to \infty\\ - h \approx r_{0} b, &&\quad b \to 0. -\end{eqnarray*} -To tackle this, we will assume that $h = F(b)$, for some kind of -$F(\cdot)$. One function that satisfies the above conditions is -$$ -F(b) = h_{\infty} \frac{2}{\pi} \arctan \left( \frac{\pi r_0}{2 -h_{\infty}} b \right). -$$ - -For satisfying results we choose $h_{\infty} = 2\cdot \texttt{interline}$ -and $r_0 = \frac 13$. - -\subsection{Height correction} - -Aside from being a smooth curve, slurs should avoid crossing -enclosed notes and their stems. - -An easy way to achieve this is to extend the slur's height, -so that the slur will curve just above any disturbing notes. - -The parameter $i$ determines the flatness of the curve. Satisfying -results have been obtained with $i = h$. - -The formula can be generalised to allow for corrections in the shape, -\begin{eqnarray*} -c_1&=& (0,0)\\ -c_2&=& (i', h')\\ -c_3&=& (b-i', h')\\ -c_4&=& (b, 0) -\end{eqnarray*} -Where -$$ -i' = h(b) (1 + i_{corr}), \quad h' = h(b) (1 + h_{corr}). -$$ - -The default values for these corrections are $0$. A $h_{corr}$ that is -negative, makes the curve flatter in the center. A $h_{corr}$ that is -positive make the curve higher. - -At every encompassed note's x position the difference $\delta _y$ -between the slur's height and the note is calculated. The greatest -$\delta _y$ is used to calculate $h_{corr}$ is by lineair extrapolation. - -However, this simple method produces satisfactory results only for -small and symmetric disturbances. - - -\subsection{Tangent method correction} - -A somewhat more elaborate\footnote{While staying in the realm -of empiric computer science} way of having a slur avoid -disturbing notes is by first defining the slur's ideal shape -and then using the height correction. The ideal shape of a -slur can be guessed by calculating the tangents of the disturbing -notes: -% a picture wouldn't hurt... -\begin{eqnarray*} - y_{disturb,l} &=& \rm{rc}_l x\\ - y_{disturb,r} &=& \rm{rc}_r + c_{3,x}, -\end{eqnarray*} -where -\begin{eqnarray*} - \rm{rc}_l &=& \frac{y_{disturb,l} - y_{encompass,1}} - {x_{disturb,l} - x_{encompass,1}}\dot x\\ - \rm{rc}_r &=& \frac{y_{encompass,n} - y_{disturb,r}} - {x_{encompass,n} - x_{disturb,r}} \dot x + c_{3,x}. -\end{eqnarray*} - -We assume that having the control points $c_2$ and $c_3$ located -on tangent$_1$ and tangent$_2$ resp. -% t: tangent -\begin{eqnarray*} - y_{tangent,l} &=& \alpha \rm{rc}_l x\\ - y_{tangent,r} &=& \alpha \rm{rc}_r + c_{3,x}. -\end{eqnarray*} - -Beautiful slurs have rather strong curvature at the extreme -control points. That's why we'll have $\alpha > 1$. -Satisfactory resulsts have been obtained with -$$ - \alpha \approx 2.4. -$$ - -The positions of control points $c_2$ and $c_3$ are obtained -by solving with the height-line -\begin{eqnarray*} - y_h &=& \rm{rc}_h + c_h. -\end{eqnarray*} - -The top-line runs through the points disturb$_{left}$ and -disturb$_{right}$. In the case that -$$ -z_{disturb,l} = z_{disturb,r}, -$$ -we'll have -$$ - \angle(y_{tangent,l},y_h) = \angle(y_{tangent,r},y_h). -$$ - - - -\section{Sizes} - -Traditional engraving uses a set of 9 standardised sizes for Staffs -(running from 0 to 8). - -We have tried to measure these (helped by a magnifying glass), and -found the staffsizes in table~\ref{fonts:staff-size}. One should note that -these are estimates, so I think there could be a measuring error of ~ -.5 pt. Moreover [Ross] states that not all engravers use exactly -those sizes. - -\begin{table}[h] - \begin{center} - \begin{tabular}{lll} -Staffsize &Numbers &Name\\ -\hline\\ -26.2pt &No. 0\\ -22.6pt &No. 1 &Giant/English\\ -21.3pt &No. 2 &Giant/English\\ -19.9pt &No. 3 &Regular, Ordinary, Common\\ -19.1pt &No. 4 &Peter\\ -17.1pt &No. 5 &Large middle\\ -15.9pt &No. 6 &Small middle\\ -13.7pt &No. 7 &Cadenza\\ -11.1pt &No. 8 &Pearl\\ - \end{tabular} - \caption{Foo} - \label{fonts:staff-size} - \end{center} -\end{table} - - - - -\section{Beams} - -\subsection{Slope} - -Traditionally, beam slopes are computed by following a large and hairy -set of rules. Some of these are talked-about in Wanske, a more -recipy-like description can be found in Ross. - -There are some problems when trying to follow these rules: -\begin{itemize} - -\item the set is not complete - -\item they are not formulated as a general rule with exceptions, but -rather as a huge case of individual rules\cite{ross} - -\item in some cases, the result is wrong or ugly (or both) - -\item they try to solve a couple of problems at a time (e.g. Ross -handles ideal slope and slope-quantisation as a paired problem) -\end{itemize} -Reading Ross it is clear that the rules presented there are certainly -not the ultimate idea of what beam(slope)s should look like, but -rather a (very much) simplified hands-on recipy for a human engraver. - -There are good reasons not to follow those rules: - -\begin{itemize} -\item One cannot expect a human engraver to solve least-squares -problems for every beam - -\item A human engravers will allways trust themselves in judging the -outcome of the applied recipy. If, in a complicated case, the result -"doesn't look good", they will ignore the rules and draw their own -beams, based on experience. - -\item The exact rules probably don't "really exist" but in the minds - of good engravers, in the form of experience -\end{itemize} - -We'll propose to do a least-squares solve. This seems to be the best -way to calculate the slope for a computerised engraver such as Lily. - -It would be nice to have some rules to catch and handle "ugly" cases, -though. In general, the slope of the beam should mirror the pitches -of the notes. If this can't be done because there simply is no -uniform trend, it would probably be best to set the slope to zero. - - -\subsection{Quantising} - -The beams should be prevented to conflict with the stafflines, -especially at small slopes. Traditionally, poor printing techniques -imposed rather strict rules for quantisation. In modern (post 1955) -music printing we see that quality has improved substantially and -obsoleted the technical justification for following some of these -strict rules, notably the avoiding of so-called wedges. - - -\subsection{Thickness and spacing} - -The spacing of double and triple beams (sixteenth and thirtysecond beams) -is the same, quadruple and quintuple (thirtyfourth and hundredtwentyeighth -beams) is wider. -All beams are equally thick. Using the layout of triple beams and the -beam-thickness $bt$ we can calculate the inter-beam spacing $ib$. - -Three beams span two interlines, including stafflines: -\begin{eqnarray*} - 2 ib + bt &=& 2 il\\ - ib &=& (2 il - bt) / 2 -\end{eqnarray*} - -We choose -\begin{eqnarray*} - bt &=& 0.48(il - st) -\end{eqnarray*} - -\subsubsection{Quadruple beams} - -If we have more than three beams they must open-up -in order to not collide with staff lines. The only valid -position that remains is for the upper beam to hang. - -\begin{eqnarray*} - 3 ib_{4+} + bt &=& 3 il\\ - ib_{4+} &=& (3 il - bt) / 3 -\end{eqnarray*} - - -\section{Layout of the source files} - -The main font (with the fixed size music glyphs) uses a the \TeX\ -logfile as a communication device. Use the specialised macros to -create and export glyphs. - -\bibliographystyle{plain} -\bibliography{engraving} - - - -\end{document} - -\begin{verbatim} -Paul Terry writes: - -Ross states that the dies (the stamps to make the symbols) come in -12 different sizes. - ->Can you tell me how big rastrals are? - -According to the Score manual: - - Rastral Size Height in millimetres - - 0 9 mm - 1 8 mm - 2 7.5 mm - 3 7 mm - 4 6.5 mm - 5 6 mm - 6 5.5 mm - -I must say, despite having been a music setter for many years, I had to -look these up - none of the publishers I work for deal in Rastral sizes -these days (they all use millimetres). diff --git a/Documentation/metadoc/hacking.texi b/Documentation/metadoc/hacking.texi deleted file mode 100644 index 42bcbee28e..0000000000 --- a/Documentation/metadoc/hacking.texi +++ /dev/null @@ -1,829 +0,0 @@ -\input texinfo @c -*-texinfo-*- -@setfilename internals.info -@settitle LilyPond internals - -@node Top, LilyPond internals, (dir), (dir) -@top - - -@menu -* LilyPond internals:: -* Overview:: -* mudela:: -* Request_engraver:: -* Graphic elements:: -* Score elements:: -* Items:: -* Spanners:: -* Future work:: -* Coding standards:: -* Making patches:: - -@end menu - -@node LilyPond internals, , Top, Top -@menu -* Overview:: Overview -* mudela:: mudela -* Request_engraver:: Request_engraver -@end menu - - -@chapter Help Needed! - -[Call for help] - -[List tasks: - -* Mutopia - -* Doco LilyPond - -* Straightforward extensions - -* GUI editors. - -] - -@chapter LilyPond internals - - -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. - -@node Overview, mudela, Top, Top -@section 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. - -@table @samp - -@item 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. - -@item 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). - -@item Prebreaking - -Breakable stuff (eg. clefs and bars) are copied into pre and -postbreaks. - -@item 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), - -@item Break calculation: - -The lines and horizontal positions of the columns are determined. - -@item 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. - -@item Postprocesing: - -Some items and all spanners need computation after the Paper_column -positions are determined. Examples: slurs, vertical positions of -staffs. - -@item Output paper - -@end table - -@node mudela, Request_engraver, Overview, Top -@section 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' - -@table @samp -@item @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. -@item @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. -@item @code{Rest_req} - Typeset a rest. -@item @code{Span_req} - This type of request typically results in the creation of a @code{Spanner} -@item @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. -@item @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. -@end table - -@node Request_engraver, , mudela, Top -@section 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 - -@example - - \type Staff < % chord - @{ \meter 2/4; [c8 c8] @} - @{\meter 2/4; [e8 e8] @} - > - -@end example - -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. - -@unnumberedsubsec example: - -@example - - c4 - -@end example - -produces: - -@example - - Note_request (duration 1/4) - Stem_request (duration 1/4) - -@end example - -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}. - - - -@node Graphic elements, , , Top -@section Graphic elements - - -Music notation is composed of a sets of interrelated glyphs. In -Lilypond every glyph usually is represented by one object, a so-called -Graphic Object. The primary relations between graphic objects involve -positions: - -@itemize -@item consecutive notes are printed left to right, grouped in a staff -@item simultaneous notes are horizontally aligned (internally grouped in -a paper column). -@item the staccato mark is horizontally centered on the note it applies -to. -@end itemize - -The abstract encoding of such relations is done with the concept -@dfn{reference point}. The reference point (in X direction) of the -staccato mark is the note it applies to. The (X) position of the -staccato mark is stored relative to the position of the note head. This -means that the staccato will always maintain a fixed offset wrt to the -note head, whereever the head is moved to. - -In the same vein, all notes on a staff have their Y positions stored -relative to an abstract object called Axis_group_spanner. If the -Axis_group_spanner of one staff is moved, the absolute Y positions of -all objects in that spanner change along, in effect causing the staff -and all its contents to move as a whole. - -Each graphic object stores a pointer and an relative offset for each -direction: one for the X-axis, one for the Y-axis. For example, the X -parent of a Note_head usually is a Note_column. The X parent of a -Note_column usually is either a Collision or a Paper_column. The X -parent of a Collision usually is a Paper_column. If the Collision -moves, all Note_heads that have that Collision as parent also move, but -the absolute position of the Paper_column does not change. - -To build a graphical score with Graphic_elements, conceptually, one -needs to have one Root object (in Lilypond: Line_of_score), and -recursively attach objects to the Root. However, due to the nature -of the context selection mechanisms, it turns out to be more -advantageous to construct the tree the other way around: first small -trees (note heads, barlines etc.) are created, and these are -subsequently composed into larger trees, which are finally hung on a -Paper_column (in X direction) or Line_of_score (in Y direction). - -The structure of the X,Y parent relations are determined by the -engravers and notation contexts: - -The most important X-axis parent relation depends on the timing: notes -that come earlier are attached to Paper_column that will be positioned -more to the left. - -The most important Y-axis relation depends on containment of contexts: -notes (created in a Thread or Voice context) are put in the staff where -the originating context lives in. - -Graphical_axis_groups are special graphic objects, that are designed to -function as a parent. The size of a Graphical_axis_groups group is the -union of its children. - -@node Score elements, , , Top - -Besides relative positions there are lots of other relations between -elements. Lilypond does not contain other specialized relation -management (Like the relative positioning code). In stead, objects can -be connected through dependencies, which sets the order in which objects -are to be processed. - -Example: the direction of a beamed stem should equal the direction of -the beam. When the stem is a added to the beam, a dependency on the -beam is set in the stem: this means that @code{Beam::do_pre_processing -()} (which does various direction related things) will be called before -@code{Stem::do_pre_processing ()}. - -The code that manages dependencies resides in the class -@code{Score_element}, a derived class of @code{Graphical_element}. The -bulk of the code handles line breaking related issues. - -To sketch the problems with line breaking: suppose a slur spans a line -break, -@example - -c4( c'''' c | \break d d )d - -@end example -In this case, the slur will appear as two parts, the first part spanning -the first three notes (the @code{c}s), the second spanning the last -three (the @code{d}s). Within Lilypond this is modeled as breaking the -slur in parts: from the Original slur, two new clones of the old slur -are made. Initially both clones depend on the six notes. After the -hairy code in Score_element, Spanner and Item which does substitutions -in sets of dependencies, the first clone depends on the first three -notes, the second on the last three. - -The major derived classes of Score_element are Item and Spanner. -An item has one horizontal position. A spanner hangs on two items. - -@node Items, , , Top -@section Items - - - -An item is a score element that is associated with only one -Paper_column. Examples are note heads, clefs, sup and superscripts, etc. -Item is a derived class of Score_element. - -The shape of an item is known before the break calculations, and line -spacing depends on the size of items: very wide items need more space -than very small ones. - -An additional complication is the behavior of items at linebreaks. For -example, when you do a time signature change, you get only one symbol. -If it occurs at a linebreak, the new time signature must be printed both -before and after the linebreak. Other `breakable symbols' such as -clefs, and bar lines also exhibit this behavior. - -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. To support this, -breakable items are generated in the three versions: original -(unbroken), left (before line break) and right (after line break). -During the line spacing, these versions are used to try how the spacing -of a line works out. - -Once the definitive spacing is determined, dependencies (and various -other pointers) are substituted such that all dependencies point at the -active items: either they point at the original, or they point at left -and right. - -@node Spanners, , , Top -@section Spanners - -Spanners are symbols that are of variable shape, eg. Slurs, beams, etc. -Spanners is a derived class of Score_element. - -The final shape can only be determined after the line breaking process. -All spanners are spanned on two items, called the left and right -boundary item. The X reference point is the left boundary item. - - -@node Future work, , , Top -@section Future work - -There are plans to unify Spanner and Item, so there will no longer be -such a clear distinction between the two. Right now, Score_elements are -always either Item or either Spanner. - -Most of the properties of a graphic object are now member variables of -the classes involved. To offer configurability, we want to move these -variables to scheme (GUILE) variables, and no longer use C++ code to -calculate them, but use Scheme functions. - -@node Coding standards, , , Top - -@chapter CodingStyle - standards while programming for GNU -LilyPond - -Functions and methods do not return errorcodes. - - -@unnumberedsubsec Languages - -C++ and Python are preferred. Perl is not. Python code should use an -indent of 8, using TAB characters. - -@unnumberedsubsec Filenames - -Definitions of classes that are only accessed via pointers -(*) or references (&) shall not be included as include files. - -filenames - -@example - ".hh" Include files - ".cc" Implementation files - ".icc" Inline definition files - ".tcc" non inline Template defs -@end example - -in emacs: - -@example - (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)) -@end example - - -The class Class_name_abbreviation is coded in @file{class-name-abbr.*} - -@unnumberedsubsec Indentation - -Standard GNU coding style is used. In emacs: - -@example - (add-hook 'c++-mode-hook - '(lambda() (c-set-style "gnu") - ) - ) -@end example - -If you like using font-lock, you can also add this to your @file{.emacs}: - -@example - (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)) - )) -@end example - -@unnumberedsubsec Classes and Types - -@example - This_is_a_class -@end example - -@unnumberedsubsec Members - -@example - Class::member () - Type Class::member_type_ - Type Class::member_type () -@end example - -the @code{type} is a Hungarian notation postfix for @code{Type}. See below - -@unnumberedsubsec 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 ()}. - -@unnumberedsubsec 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. - -@unnumberedsubsec Comments - -The source is commented in the DOC++ style. Check out doc++ at -@uref{http://www.zib.de/Visual/software/doc++/index.html} - -@example - - /* - 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 - @} - @}; - -@end example - - -Unfortunately most of the code isn't really documented that good. - -@unnumberedsubsec Members (2) - -Standard methods: - -@example - - ///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 (..) - -@end example - -@unnumberedsubsec Constructor - -Every class should have a default constructor. - -Don't use non-default constructors if this can be avoided: - -@example - - Foo f(1) - -@end example - -is less readable than - -@example - - Foo f; - f.x = 1 - -@end example - -or - -@example - - Foo f(Foo_convert::int_to_foo (1)) - -@end example - -@unnumberedsec Hungarian notation naming convention - -Proposed is a naming convention derived from the so-called -@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all -uppercase, with the parts of the names separated by underscores. - -The hungarian notation is to be used when variables are not declared -near usage (mostly in member variables and functions). - -@unnumberedsubsec Types - -@table @samp -@item @code{byte} - unsigned char. (The postfix _by is ambiguous) -@item @code{b} - bool -@item @code{bi} - bit -@item @code{ch} - char -@item @code{f} - float -@item @code{i} - signed integer -@item @code{str} - string class -@item @code{sz} - Zero terminated c string -@item @code{u} - unsigned integer -@end table - -@unnumberedsubsec User defined types - -@example - - /** Slur blah. blah. - (slur) - */ - class Slur @{@}; - Slur* slur_p = new Slur; - -@end example - -@unnumberedsubsec Modifiers - -The following types modify the meaning of the prefix. -These are preceded by the prefixes: - -@table @samp -@item @code{a} - array -@item @code{array} - user built array. -@item @code{c} - const. Note that the proper order is @code{Type const} - i.s.o. @code{const Type} -@item @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. -@item @code{l} - temporary pointer to object (link) -@item @code{p} - pointer to newed object -@item @code{r} - reference -@end table - -@unnumberedsubsec 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. - -@example - -foo_global_i: a global variable of type int commonly called "foo". - -@end example - -static class members do not need the static_ prefix in the name (the -Class::var notation usually makes it clear that it is static) - -@table @samp -@item @code{loop_i} - Variable loop: an integer -@item @code{u} - Temporary variable: an unsigned integer -@item @code{test_ch} - Variable test: a character -@item @code{first_name_str} - Variable first_name: a String class object -@item @code{last_name_ch_a} - Variable last_name: a @code{char} array -@item @code{foo_i_p} - Variable foo: an @code{Int*} that you must delete -@item @code{bar_i_l} - Variable bar: an @code{Int*} that you must not delete -@end table - -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 - -@example - - static Array foo - -@end example - -@code{foo} can be described as "the static int-pointer user-array", so you get - -@example - - foo_static_l_arr - -@end example - - -@unnumberedsec 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. - -@node Making patches, , , Top - - -@unnumberedsec name - - -PATCHES - track and distribute your code changes - -This page documents how to distribute your changes to GNU lilypond - -We would like to have unified context diffs with full pathnames. A -script automating supplied with Lily. - -Distributing a change normally goes like this: - -@itemize @bullet -@item make your fix/add your code -@item Add changes to CHANGES, and add yourself to Documentation/topdocs/AUTHORS.texi -@item generate a patch, -@item e-mail your patch to one of the mailing lists - gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org -@end itemize - -Please do not send entire files, even if the patch is bigger than the -original. A patch makes it clear what is changed, and it won't -overwrite previous (not yet released) changes. - -@unnumberedsec Generating a patch - -Simple version: run - -@example - make -C lilypond-x.y.z/ distclean - make -C lilypond-x.y.z.NEW/ distclean - diff -urN lilypond-x.y.z/ lilypond-x.y.z.NEW/ -@end example - -Complicated (but automated) version: - -In @file{VERSION}, set MY_PATCH_LEVEL: - -@example - - VERSION: - ... - MY_PATCH_LEVEL=jcn1 - -@end example - -In @file{CHANGES}, enter a summary of changes: - -@example - pl 0.1.73.jcn1 - - added PATCHES.texi -@end example - -Then, from the top of Lily's source tree, type - -@example - make release -@end example - -These handy python scripts assume a directory structure which looks -like: - -@example - - lilypond -> lilypond-x.y.z # symlink to development directory - lilypond-x.y.z/ # current development - patches/ # patches between different releases - releases/ # .tar.gz releases - -@end example - -(Some scripts also assume this lives in @file{$HOME/usr/src}). - - -@unnumberedsec Applying patches - - -If you're following LilyPond development regularly, you probably want to -download just the patch for each subsequent release. -After downloading the patch (into the patches directory, of course), simply -apply it: - -@example - - gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E - -@end example - -and don't forget to make automatically generated files: - -@example - - autoconf footnote(patches don't include automatically generated files, - i.e. file(configure) and files generated by file(configure).) - - configure - -@end example - - -@bye - - diff --git a/Documentation/metadoc/lilypond-overview.doc b/Documentation/metadoc/lilypond-overview.doc deleted file mode 100644 index a408a9e8eb..0000000000 --- a/Documentation/metadoc/lilypond-overview.doc +++ /dev/null @@ -1,743 +0,0 @@ -%-*-LaTeX-*- - -\documentclass{article} -\usepackage{a4} -\def\postMudelaExample{\setlength{\parindent}{1em}} -\title{LilyPond, a Music Typesetter} -\author{HWN} -\usepackage{musicnotes} -\usepackage{graphics} - - -\begin{document} -\maketitle - -[THIS IS WORK IN PROGRESS. THIS IS NOT FINISHED] - -% -*-LaTeX-*- -\section{Introduction} - -The Internet has become a popular medium for collaborative work on -information. Its success is partly due to its use of simple, text-based -formats. Examples of these formats are HTML and \LaTeX. Anyone can -produce or modify such files using nothing but a text editor, they are -easily processed with run-of-the-mill text tools, and they can be -integrated into other text-based formats. - -Software for processing this information and presenting these formats -in an elegant form is available freely (Netscape, \LaTeX, etc.). -Ubiquitousness of the software and simplicity of the formats have -revolutionised the way people publish text-based information -nowadays. - -In the field of performed music, where the presentation takes the form -of sheet music, such a revolution has not started yet. Let us review -some alternatives that have been available for transmitting sheet -music until now: -\begin{itemize} -\item MIDI\cite{midi}. This format was designed for interchanging performances - of music; one should think of it as a glorified tape recorder - format. It needs dedicated editors, since it is binary. It does - not provide enough information for producing musical scores: some of - the abstract musical content of what is performed is thrown away. - -\item PostScript\cite{Postscript}. This format is a printer control - language. Printed musical scores can be transmitted in PostScript, - but once a score is converted to PostScript, it is virtually - impossible to modify the score in a meaningful way. - -\item Formats for various notation programs. Notation programs either - work with binary formats (e.g., NIFF\cite{niff-web}), need specific - platforms (e.g., Sibelius\cite{sibelius}), are proprietary or - non-portable tools themselves (idem), produce inadequate output - (e.g., MUP\cite{mup}), are based on graphical content (e.g., - MusixTeX\cite{musixtex1}), limit themselves to specific subdomains - (e.g., ABC\cite{abc2mtex}), or require considerable skill and - knowledge to use (e.g., SCORE\cite{score}) - -\item SMDL\cite{smdl-web}. This is a very rich ASCII format, that is - designed for storing many types of music. Unfortunately, there is - no implementation of a program to print music from SMDL available. - Moreover, SMDL is so verbose, that it is not suitable for human - production. - -\item TAB\cite{tablature-web}. Tab (short for tablature) is a popular - format, for interchanging music over e-mail, but it can only be used - for guitar music. -\end{itemize} - -In summary, sheet music is not published and edited on a wide scale -across the internet because no format for music -interchange exists that is: -\begin{itemize} -\item open, i.e., with publically available specifications. -\item based on ASCII, and therefore suitable for human consumption and - production. -\item rich enough for producing publication quality sheet music from - it. -\item based on musical content (unlike, for example, PostScript), and - therefore suitable for making modifications. -\item accompanied by tools for processing it that are freely available - across multiple platforms. -\end{itemize} - - -With the creation of LilyPond, we have tried to create both a -convenient format for storing sheet music, and a portable, -high-quality implementation of a compiler, that compiles the input -into a printable score. You can find a small example of LilyPond -input along with output in Figure~\ref{fig:intro-fig}. -% -\begin{figure}[htbp] - \begin{center} -\begin[verbatim]{mudela} - \score { - \notes - \context GrandStaff < - \transpose c'' { c4 c4 g4 g4 a4 a4 g2 } - { \clef "bass"; c4 c'4 - \context Staff f'4 c'4 e'4 c'4 } - > - \paper { - linewidth = -1.0\cm ; - } - } -\end{mudela} - \caption{A small example of LilyPond input} - \label{fig:intro-fig} - \end{center} -\end{figure} -% - - -The input language encodes musical events (such as notes and rests) on -the basis of their time-ordering. For example, the grammar includes -constructs that specify that notes start simultaneous and that notes -are to be played in sequence. In this encoding some context that is -present in sheet music is lost. - -The compiler reconstructs the notation from the encoded music. Its -operation comprises four different steps (see -Figure~\ref{fig:intro-steps}). - -\begin{description} -\item[Parsing] During parsing, the input is converted in a syntax tree. - -\item[Interpreting] In the \emph{interpreting} step, it is determined - which symbols have to be printed. Objects that correspond to - notation (\emph{Graphical objects}) are created from the syntax tree - in this phase. Generally speaking, for every symbol printed there is - one graphical object. These objects are incomplete: their position - and their final shape is unknown. - - The context that was lost by encoding the input in a language is - reconstructed during this conversion. -\item[Formatting] The next step is determing where symbols are to be - placed, this is called \emph{formatting}. -\item[Outputting] - Finally, all Graphical objects are outputted as PostScript or \TeX\ code. -\end{description} - -\def\staffsym{\vbox to 16pt{ - \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip - \vfil - \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip - \vfil - \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip - \vfil - \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip - \vfil - \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip -}} - -\def\vspacer{\vbox to 20pt{\vss}} -\begin{figure}[h] -\def\spacedhbox#1{\hbox{\ #1\ }} -\begin{eqnarray*} - {\spacedhbox{Input}\atop \hbox{\texttt{\{c8 c8\}}}} {\spacedhbox{Parsing}\atop\longrightarrow} - {\spacedhbox{Syntax tree}\atop\spacedhbox{\textsf{Sequential(Note,Note)}}} - {\spacedhbox{Interpreting}\atop\longrightarrow}\\ - \vspacer\\ - {\spacedhbox{Graphic objects}\atop\spacedhbox{\texttrebleclef \textquarterhead\texteighthflag\textquarterhead\texteighthflag \staffsym }} - {\spacedhbox{Formatting}\atop\longrightarrow} - {\spacedhbox{Formatted objects}\atop\hbox{ - \mudela{c''8 c''8} - }}\\ -\vspacer\\ - {\spacedhbox{Outputting}\atop\longrightarrow} - {\spacedhbox{PostScript code}\atop\hbox{\texttt{\%!PS-Adobe}\ldots}} -\end{eqnarray*} - \caption{Parsing, Interpreting, Formatting and Outputting} - \label{fig:intro-steps} -\end{figure} - - -The second step, the interpretation phase of the compiler, can be -manipulated as a separate entity: the interpretation process is -composed of many separate modules, and the behaviour of the modules is -parameterised. By recombining these interpretation modules, -and changing parameter settings, the same piece of music can be -printed differently, as is shown in Figure~\ref{fig:intro-interpret}. - -This makes it easy to extend the program. Moreover, this enables the -same music to be printed in different versions, e.g., in a conductors -score and in extracted parts. - - -\begin{figure}[h] - \begin{center} - \begin{mudela} - \score { - \notes - \context GrandStaff < - \transpose c'' { c4 c4 g4 g4 a4 a4 g2 } - { \clef "bass"; c4 c'4 - \context Staff f'4 c'4 e'4 c'4 } - > - \paper { - linewidth = -1.0\cm ; - \translator { - \VoiceContext - \remove "Stem_engraver"; - } - \translator { - \StaffContext - numberOfStaffLines = 3; - } - } - } - \end{mudela} - \caption{The interpretation phase can be manipulated: the same - music as in Figure~\ref{fig:intro-fig} is interpreted - differently: three staff lines and no stems.} - \label{fig:intro-interpret} - \end{center} -\end{figure} - - - -\section{Preliminaries} - -To understand the rest of the article, it is necessary to know -something about music notation and music typography. Since both -communicate music, we will explain some characteristics of instruments -and western music that motivate some notational constructs. - -\subsection{Music} - -Music notation is meant to be read by human performers. They sing or -play instruments that can produce sounds of different pitches. These -sounds are called \emph{notes}. Additionally, the sounds can be -articulated in differents ways, e.g., staccato (short and separated) -or legato (fluently bound together). The loudness of the notes can -also be varied. Changes in loudness are called \emph{dynamics}. - -Silence is also an element of music. The musical terminology for -silence within music is \emph{rest}. - -The basic unit of pitch is the \emph{octave}. The octave corresponds -to a frequency ratio of 1:2. For example the pitch denoted by a' -(frequency: 440 hertz) is one octave lower than a'' (frequency: 880 -hertz). Various instruments have a limited \emph{pitch range}, for -example, a trumpet has a range of about 2.5 octaves. Not all -instruments have ranges in the same register: a tuba also has a range -of 2.5 octaves, but the range of the tuba is much lower. - -Musicology has a confusing mix of relative and absolute measures for -pitches: the term `octave' refers to both a difference between two -pitches (the frequency ratio of 1:2), and to a range of pitches. For -example, the term `[eengestreept] octave' refers to the pitch range -between 261.6 Hz and 523.3 Hz. - - -The octave is divided into smaller pitch steps. In modern western -music, every octave is divided into twelve approximately equidistant -pitch steps, and each step is called a \emph{semitone}. Usually, the -pitches in a musical piece come from a smaller subset of these twelve -possible pitches. This smaller subset along with the musical -functions fo the pitches is called the -\emph{tonality}\footnote{Tonality also refers to the relations between - and functions of certain pitches. Since these do not have any - impact on notation, we ignore this} of the piece. - - -The standard tonality that forms the basis of music notation -(the key of C major) is a set of seven pitches within every octave. -Each of these seven is denoted by a name. In English, these are names -are (in rising pitch) denoted by c, d, e, f, g, a and b. Pitches that -are a semitone higher or lower than one of these seven can be -represented by suffixing the name with `sharp' or `flat' -respectively (this is called an \emph{chromatic alteration}). - -A pitch therefore can be fully specified by a combination of the -octave number, the note name and a chromatic alteration. -Figure~\ref{fig:intro-pitches} shows the relation between names and -frequencies. - - - - -\begin{figure}[h] - \begin{center} - [te doen] - \end{center} - \caption{Pitches in western music. The octave number is denoted - by a superscript.} - \label{fig:intro-pitches} -\end{figure} - - -Many instruments can produce more than one note at the same time, e.g. -pianos and guitars. When more notes are played simultaneously, they -form a so-called \emph{chord}. - -The unit of duration is the \emph{beat}. When playing, the tempo is -determined by setting the number of beats per minute. In western -music, beats are often stressed in a regular pattern: for example -Waltzes have a stress pattern that is strong-weak-weak, i.e. every -note that starts on a `strong' beat is louder and has more pronounced -articulation. This stress pattern is called \emph{meter}. - -\subsection{Music notation} - -Music notation is a system that tries to represent musical ideas -through printed symbols. Music notation has no precise definition, -but most conventions have described in reference manuals on music -notation\cite{read-notation}. - -In music notation, sounds and silences are represented by symbols that -are called note and rest respectively.\footnote{These names serve a - double purpose: the same terms are used to denote the musical - concepts.} The shape of notes and rests indicates their duration -(See figure~\ref{noteshapes}) relative to the whole note. - - -\begin{figure}[h] - \begin{center} -\begin{mudela} - \score { - \notes \transpose c''{ c\longa*1/4 c\breve*1/2 c1 c2 c4 c8 c16 c32 c64 } - \paper { - \translator { - \StaffContext - \remove "Staff_symbol_engraver"; - \remove "Time_signature_engraver"; -% \remove "Bar_engraver"; - \remove "Clef_engraver"; - } -linewidth = -1.; - } -} -\end{mudela} -\begin{mudela} - \score { - \notes \transpose c''\context Staff { r\longa*1/4 r\breve*1/2 r1 r2 r4 r8 r16 r32 r64 } - \paper { - \translator { - \StaffContext - \remove "Staff_symbol_engraver"; - \remove "Time_signature_engraver"; -% \remove "Bar_engraver"; - \remove "Clef_engraver"; - } - linewidth = -1.; - } -} -\end{mudela} - \caption{Note and rest shapes encode the length. At the top notes - are shown, at the bottom rests. From left to right a quadruple - note (\emph{longa}), double (\emph{breve}), whole, half, - quarter, eigth, sixteenth, thirtysecond and sixtyfourth. Each - note has half of the duration of its predecessor.} - \label{fig:noteshapes} -\end{center} -\end{figure} - - -Notes are printed in a grid of horizontal lines called \emph{staff} to -denote their pitch: each line represents the pitch of from the -standard scale (c, d, e, f, g, a, b). The reference point is the -\emph{clef}, eg., the treble clef marks the location of the $g^1$ -pitch. The notes are printed in their time order, from left to right. - - -\begin{figure}[h] - \begin{center} - \begin{mudela} - \score { \notes { - a4 b c d e f g a \clef bass; - a4 b c d e f g a \clef alto; - a4 b c d e f g a \clef treble; - } - \paper { linewidth = 15.\cm; } - } - \end{mudela} - \caption{Pitches ranging from $a, b, c',\ldots a'$, in different - clefs. From left right the bass, alto and treble clef are - featured.} - \label{fig:pitches} - \end{center} -\end{figure} - -The chromatic alterations are indicated by printing a flat sign or a -sharp sign in front of the note head. If these chromatic alterations -occur systematically (if they are part of the tonality of the piece), -then this indicated with a \emph{key signature}. This is a list of -sharp/flat signs which is printed next to the clef. - -Articulation is notated by marking the note shapes wedges, hats and -dots all indicate specific articulations. If the notes are to be -bound fluently (legato), the note shapes are encompassed by a smooth -curve called \emph{slur}, - -\begin{figure}[h] - \begin{center} - \begin{mudela} - c'4-> c'4-. g'4 ( b'4 ) g''4 - \end{mudela} - \caption{Some articulations. From left to right: extra stress - (\emph{marcato}), short (staccato), slurred notes (legato).} - \label{fig:articulation} - \end{center} -\end{figure} - - - -Dynamics are notated in two ways: absolute dynamics are indicated by -letters: \textbf{f} (from Italian ``forte'') stands for loud, -\textbf{p} (from Italian ``piano'') means soft. Gradual changes in -loudness are notated by (de)crescendos. These are hairpin like shapes -below the staff. - -\begin{figure}[h] - \begin{center} - \begin{mudela} - g'4\pp \< g'4 \! g'4 \ff \> g'4 g' \! g'\ppp - \end{mudela} - \caption{Dynamics: start very soft (pp), grow to loud (ff) and - decrease to extremely soft (ppp)} - \label{fig:dynamics} - \end{center} -\end{figure} - - -The meter is indicated by barlines: every start of the stress pattern -is preceded by a vertical line, the \emph{bar line}. The space -between two bar lines is called measure. It is therefore the unit of -the rhythmic pattern. - -The time signature also indicates what kind of rhythmic pattern is -desired. The time signature takes the form of two numbers stacked -vertically. The top number is the number of beats in one measure, the -bottom number is the duration (relative to the whole note) of the note -that takes one beat. Example: 2/4 time signature means ``two beats -per measure, and a quarter note takes one beat'' - -Chords are written by attaching multiple note heads to one stem. When -the composer wants to emphasize the horizontal relationships between -notes, the simultaneous notes can be written as voices (where every -note head has its own stem). A small example is given in -Figure~\ref{fig:simultaneous}. - -\begin{figure}[h] - \begin{center} - \begin{mudela} - \relative c'' {\time 2/4; - \context Staff < \context Voice = VA{ - \stemdown - c4 d - b16 b b b b b b b } - \context Voice = VB { - \stemup e4 f g8 g4 g8 } > - } - \end{mudela} - \caption{Notes sounding together. Chord notation (left, before - the bar line) emphasizes vertical relations, voice notation - emphasizes horizontal relations. Separate voices needn't have - synchronous rhythms (third measure). - } - \label{fig:simultaneous} - \end{center} -\end{figure} - -Separate voices do not have to share one rhythmic pattern---this is -also demonstrated in Figure~\ref{fig:simultaneous}--- they are in a sense%vaag -independent. A different way to express this in notation, is by -printing each voice on a different staff. This is customary when -writing for piano (both left and right hand have a staff of their own) -and for ensemble (every instrument has a staff of its own). - - - -\subsection{Music typography} - -Music typography is the art of placing symbols in esthetically -pleasing configuration. Little is explicitly known about music -typography. There are only a few reference works -available\cite{ross,wanske}. Most of the knowledge of this art has -been transmitted verbally, and was subsequently lost. - -The motivation behind choices in typography is to represent the idea -as clearly as possible. Among others, this results in the following -guidelines: -\begin{itemize} -\item The printed score should use visual hints to accentuate the - musical content -\item The printed score should not contain distracting elements, such - as large empty regions or blotted regions. -\end{itemize} - -An example of the first guideline in action is the horizontal spacing. -The amount of space following a note should reflect the duration of -that note: short notes get a small amount of space, long notes larger -amounts. Such spacing constraints can be subtle, for the -``amount of space'' is only the impression that should be conveyed; there -has to be some correction for optical illusions. See -Figure~\ref{fig:spacing}. - -\begin{figure}[h] - \begin{center} - \begin{mudela} - \relative c'' { \time 3/4; c16 c c c c8 c8 | f4 f, f' } - \end{mudela} - \caption{Spacing conveys information about duration. Sixteenth - notes at the left get less space than quarter notes in the - middle. Spacing is ``visual'', there should be more space - after the first note of the last measure, and less after second. } - \label{fig:spacing} - \end{center} -\end{figure} - -Another example of music typography is clearly visible in collisions. -When chords or separate voices are printed, the notes that start at -the same time should be printed aligned (ie., with the same $x$ -position). If the pitches are close to each other, the note heads -would collide. To prevent this, some notes (or note heads) have to be -shifted horizontally. An example of this is given in -Figure~\ref{fig:collision}. -\begin{figure}[h] - \begin{center} - [todo] - \caption{Collisions} - \label{fig:collision} - \end{center} -\end{figure} - -\bibliographystyle{hw-plain} -\bibliography{engraving,boeken,colorado,computer-notation,other-packages} - -\section{Requirements} - - -\section{Approach} - -\subsection{Input} - -The input format consists of combining a symbolic representation of -music with style sheet that describes how the symbolic presentation -can converted to notation. The symbolic representation is based on a -context free language called \textsf{music}. Music is a recursively -defined construction in the input language. It can be constructed by -combining lists of \textsf{music} sequentially or parallel or from -terminals like notes or lyrics. - -The grammar for \textsf{music} is listed below. It has been edited to -leave out the syntactic and ergonomic details. - -\begin{center} - \begin{tabular}{ll} -Music: & SimpleMusic\\ - & $|$ REPEATED int Music ALTERNATIVE MusicList\\ - & $|$ SIMULTANEOUS MusicList\\ - & $|$ SEQUENTIAL MusicList\\ - & $|$ CONTEXT STRING '=' STRING Music\\ - & $|$ TIMES int int Music \\ - & $|$ TRANSPOSE PITCH Music \\ -SimpleMusic: & $|$ Note\\ - & $|$ Lyric\\ - & $|$ Rest\\ - & $|$ Chord\\ - & $|$ Command\\ -Command: & METERCHANGE\\ - & $|$ CLEFCHANGE\\ - &$|$ PROPERTY STRING '=' STRING\\ -Chord: &PitchList DURATION\\ -Rest: &REST DURATION\\ -Lyric: &STRING DURATION\\ -Note: &PITCH DURATION\\ -\end{tabular} -\end{center} - -The terminals are both purely musical concepts that have a duration, -and take a non-zero amount of musical time, like notes and lyrics, and -commands that behave as if they have no duration.\footnote{The - PROPERTY command is a generic mechanism for controlling the - interpretation, i.e. the musical style sheets. See [forward ref]} - -The nonterminal productions can -\begin{itemize} -\item Some productions combine multiple elements: one can specify that - element are to be played in sequence, simultaneously or repetitively. -\item There are productions for transposing music, and for dilating - durations of music: the TIMES production can be used to encode a - triplet.\footnote{A triplet is a group of three notes marked by a - bracket, that are played 3/2 times faster.} -\item - There are productions that give directions to the interpretation - engine (the CONTEXT production) -\end{itemize} - - -\section{Context in notation} - -Music notation relies heavily on context. Notational symbols do not -have meaning if they are not surrounded by other context elements. In -this section we give some examples how the reader uses this context do -derive meaning of a piece of notation. We will focus on the prime -example of context: the staff. - -A staff is the grid of five horizontal lines, but it contains more components : -\begin{itemize} -\item A staff can have a key signature (printed at the left) -\item A staff can have a time signature (printed at the left) -\item A staff has bar lines -\item A staff has a clef (printed at the left) -\end{itemize} - -It is still possible to print notes without these components, but one -cannot determine the meaning of the notes. -\begin{mudela} -\score{ -\notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 } -\paper { - linewidth = -1.; - \translator { - \StaffContext - \remove "Time_signature_engraver"; -% \remove "Bar_engraver"; - \remove "Staff_symbol_engraver"; - \remove "Clef_engraver"; - \remove "Key_engraver"; - } - } -} -\end{mudela} - -As you can see, you can still make out the general form of the melody -and the rhythm that is to be played, but the notation is difficult to -read and the musical information is not complete. The stress -pattern in the notes can't be deduced from this output. For this, we -need a time signature. Adding barlines helps with finding the strong -and weak beats. -\begin{mudela} -\score { - \notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 } - \paper{ - linewidth = -1.; -\translator{ - \StaffContext - \remove "Staff_symbol_engraver"; - \remove "Clef_engraver"; - \remove "Key_engraver";} - } - } -\end{mudela} - -It is impossible to deduce the exact pitch of the notes. One needs a -clef to do so. Staff lines help the eye in determining the vertical -position of a note wrt. to the clef. -\begin{mudela} -\score { - \notes \relative c' {\clef alto; \time 2/4; g'4 c,4 a'4 f4 e c d2 } - \paper { - linewidth = -1.; - } -} -\end{mudela} - -Now you know the pitch of the notes: you look at the start of the line -and see a clef, and with this clef, you can determine the notated pitches. -You have found the em(context) in which the notation is to be -interpreted! - - -\section{Interpretation context} - -Context (clef, time signature etc.) determines the relationship -between musical and its notation in notes. Because LilyPond writes -notation, context works the other way around for LilyPond: with -context a piece of music can be converted to notation. - -A reader remembers this context while reading the notation from left -to right. By analogy, LilyPond constructs this context while -constructing notes from left to right. This is what happens in the -``Interpretation'' phase from~\ref{fig:intro-fig}. In LilyPond, the -state of this context is a set of variables with their values; A staff -context contains variables like - -\begin{itemize} -\item current clef -\item current time signature -\item current key -\end{itemize} - -These variables determine when and how clefs, time signatures, bar -lines and accidentals are printed. - - -Staff is not the only form of context in notation. In polyphonic -music, the stem direction shows which notes form a voice: all notes of -the same voice have stems pointing in the same direction. The value -of this variable determines the appearance of the printed stems. - -In LilyPond ``Notation context'' is abstracted to a data structure -that is used, constructed and modified during the interpretation -phase. It contains context properties, and is responsible for -creating notational elements: the staff context creates symbols for -clefs, time signatures and key signatures. The Voice context creates -stems, note heads. - -For the fragment of polyphonic music below, -\begin{mudela} - \context Staff { c'4 < { \stemup c'4 } \context Voice = VB { \stemdown a4 } > } -\end{mudela} -A staff context is created. Within this staff context (which printed -the clef), a Voice context is created, which prints the first note. -Then, a second Voice context is created, with stem direction set to -``up'', and the direction for the other is set to down. Both Voice -contexts are still part of the same Staff context. - -In the same way, multiple staff scores are created: within the score -context, multiple staff contexts are created. Every staff context -creates the notation associated with a staff. - -\section{Discussion} - - - -\end{document} - -The complexity of music notation was tackled by adopting a modular -design: both the formatting system (which encodes the esthetic rules of -notation), and the interpretation system (which encodes the semantic -rules) are highly modular. - - -The difficulty in creating a format for music notation is rooted in -the fact that music is multi dimensional: each sound has its own -duration, pitch, loudness and articulation. Additionally, multiple -sounds may be played simultaneously. Because of this, there is no -obvious way to ``flatten'' music into a context-free language. - -The difficulty in creating a printing engine is rooted in the fact -that music notation complicated: it is very large graphical -``language'' with many arbitrary esthetic and semantic conventions. -Building a system that formats full fledged musical notation is a -challenge in itself, regardless of whether it is part of a compiler or -an editor. - -The fact that music and its notation are of a different nature, -implies that the conversion between input notation is non-trivial. - -In LilyPond we solved the above problem in the following way: - diff --git a/Documentation/metadoc/musicnotes.sty b/Documentation/metadoc/musicnotes.sty deleted file mode 100644 index 31d2f83a9c..0000000000 --- a/Documentation/metadoc/musicnotes.sty +++ /dev/null @@ -1,43 +0,0 @@ - -\input lilyponddefs - -\def\fetdef#1#2{% - \def#1{\hbox{\char#2}}} - -% huh? from where -\input feta20.sty - -\font\fetasixteenfont=feta16 -\font\fetaelevenfont=feta11 -\def\fetafont{\fetasixteenfont} - -\newdimen\ild -\ild=4pt -\newdimen\stemthick -\stemthick=0.4pt - -\def\eighthstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt\raise - 3.5ex\hbox{\eighthflag}}} -\def\texteighthflag{{\fetafont\raise 0ex\hbox{\fetafont\eighthflag}}} -\def\textdeighthflag{{\fetafont\raise 0ex\hbox{\deighthflag}}} - -\def\texteighthnote{{\hbox{\hbox{\fetafont\quartball}\kern - -0.5\stemthick\eighthstem}}} -\def\quarterstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt}} -\def\textquarterstem{\quarterstem} -\def\textchord{{\hbox{\fetafont\lower.5ex\hbox to - 0pt{\textquarterhead}\raise.5ex\hbox{\textquarterhead}\kern - -0.5\stemthick\eighthstem}}} -\def\textbassclef{\hbox{\fetafont\bassclef}} -\def\texttrebleclef{\hbox{\fetafont\trebleclef}} -\def\textslur{\embeddedps{9.378744 -3.171539 3.923099 -3.171539 0.000000 0.000000 12.800000 0.000000 3.672177 -3.672177 9.127823 -3.672177 12.800000 0.000000 0.000000 0.000000 draw_slur}} - -\def\textmarcato{{\fetafont\raise 1ex\hbox{\hskip 1ex\sforzatoaccent}}} - - -\def\textquarterhead{\hbox{\fetafont\raise 2.5pt\hbox{\quartball}}} -\def\texteighthstem{\hbox{\lower 5pt\hbox{\eighthstem}}} -\def\texthalfnote{{\hbox{\hbox{\fetafont\halfball}\kern -0.5\stemthick\quarterstem}}} -\def\textquarternote{{\hbox{\hbox{\fetafont\quartball}\kern -0.5\stemthick\quarterstem}}} -\def\textflat{{\fetafont\raise 1ex\hbox{\flat}}} -\def\textsharp{{\fetafont\raise1ex\hbox{\sharp}}} diff --git a/Documentation/metadoc/regression-test.tely b/Documentation/metadoc/regression-test.tely deleted file mode 100644 index 24e4d58902..0000000000 --- a/Documentation/metadoc/regression-test.tely +++ /dev/null @@ -1,312 +0,0 @@ -\input texinfo @c -*-texinfo-*- vim:tw=72 -@setfilename regression-test.info -@settitle LilyPond Regression test - -@c fool ls-latex -@ignore -@author Han-Wen Nienhuys and Jan Nieuwenhuizen -@title LilyPond Regression test -@end ignore - -@node Top, , , - -@section Introduction - -This document tries give an brief overview of LilyPond features. When -the text correspond with the shown notation, we consider LilyPond -Officially BugFree (tm). This document is intended for finding bugs, -and documenting bugfixes. - -@section Notes and rests - -Rests. Note that the dot of 8th, 16th and 32nd rests rest should be -next to the top of the rest. All rests except the whole rest are -centered on the middle staff line. - -@mudelafile{rest.fly} - -Note head shapes are settable. The stem endings should be adjusted -per note head. If you want different note head styles on one stem, -you must create a special context called Thread. - -@mudelafile{noteheadstyle.ly} - -Noteheads can have dots, and ---although this is bad style in duple -meters--- rests can too. Augmentation dots should never be printed on -a staff line, but rather be shifted vertically. They should go up, but -in case of multiple parts, the down stems have down shifted dots. -(Wanske p. 186) In case of chords, all dots should be in a column. -The dots go along as rests are shifted to avoid collisions. - -@mudelafile{dots.fly} - -Multiple measure rests do not collide with barlines and clefs. They -are not expanded when you set @code{Score.SkipBars}. Although the -multi-measure-rest is a Spanner, minimum distances are set to keep it -colliding from barlines. - -@mudelafile{multi-measure-rest.ly} - -@section Stems - -Stem tremolos (official naming?) or rolls are tremolo signs that look -like beam segments crossing stems. If the stem is in a beam, the -tremolo must be parallel to the beam. If the stem is invisible -(eg. on a whole note), the tremolo must be centered on the note. - -@mudelafile{stem-tremolo.ly} - -Chord tremolos look like beams, but are a kind of repeat symbol. -To avoid confusion, chord tremolo beams do not reach the stems, but -leave a gap. Chord tremolo beams on half notes are not ambiguous, -as half notes cannot appear in a regular beam, and should reach the -stems. - -@mudelafile{chord-tremolo.sly} - -Beams, stems and noteheads often have communication troubles, since -the two systems for y dimensions (1 unit = staffspace, 1 unit = 1 -point) are mixed. - -Stems, beams, ties and slurs should behave similarly, when placed -on the middle staff line. Of course stem-direction is down for high -notes, and up for low notes. - -@mudelafile{stem-direction.sly} - -Similarly, if @code{stem_default_neutral_direction} is set to @code{-1}. - -@mudelafile{stem-direction-down.ly} - -@section Scripts - -The staccato dot (and all scripts with follow-into-staff set), must -not be on staff lines. - -@mudelafile{staccato-pos.sly} - -@section Grace notes - -Grace notes are typeset as an encapsulated piece of music. You can -have beams, notes, chords, stems etc. within a @code{\grace} section. -Slurs that start within a grace section, but aren't ended are attached -to the next normal note. Grace notes have zero duration. If there -are tuplets, the grace notes won't be under the brace. Grace notes -can have accidentals, but they are (currently) spaced at a fixed -distance. Grace notes (of course) come before the accidentals of the -main note. Grace notes can also be positioned after the main note. - -@mudelafile{grace.ly} - - -@section Beams, slurs and other spanners - -Beaming is generated automatically. Beams may cross bar lines. In that -case, line breaks are forbidden. Yet clef and key signatures are -hidden just as with breakable bar lines. - -@mudelafile{beaming.ly} - -Beams should behave reasonably well, even under extreme circumstances. -Stems may be short, but noteheads should never touch the beam. - -@mudelafile{beam-extreme.ly} - -Beams should always reach the middle staff line, the second beam -counting from the note head side, should never be lower than the -second staff line. This does not hold for grace note beams. - -@mudelafile{beam-position.sly} - -Slurs should look nice and symmetric. The curvature may increase -only to avoid noteheads, and as little as possible. - -@mudelafile{slur-symmetry.ly} -@mudelafile{slur-symmetry-1.ly} - -Ties are strictly horizontal. They are placed in between note heads. -The horizontal middle should not overlap with a staffline. - -@mudelafile{tie.ly} - -Beams can be typeset over fixed distance aligned staffs, beam -beautification doesn't really work, but knees do. Beams should be -behave well, wherever the switching point is. - -@mudelafile{beam-interstaff.ly} - -The same goes for slurs. They behave decently when broken across -linebreak. - -@mudelafile{slur-interstaff.ly} - -Tuplets are indicated by a bracket with a number. There should be no -bracket if there is one beam that matches the length of the tuplet. -The bracket does not interfere with the stafflines, and the number is -centered in the gap in the bracket. - -@mudelafile{tup.ly} - -@section Repeats - -LilyPond has three modes for repeats: folded, unfolded and -semi-unfolded. Unfolded repeats are fully written out. Semi unfolded -repeats have the body written and all alternatives sequentially. -Folded repeats have the body written and all alternatives -simultaneously. If the number of alternatives is larger than the -repeat count, the excess alternatives are ignored. If the number of -alternatives is smaller, the first alternative is multiplied to get to -the number of repeats. - -Unfolded behavior: - -@mudelafile{repeat-unfold.ly} - -Volta (Semi folded) behavior. Voltas can start on non-barline moments. -If they don't barlines should still be shown. - -@mudelafile{repeat-volta.ly} - -Folded. This doesn't make sense without alternatives, but it works. - -@mudelafile{repeat-fold.ly} - -@section Lyrics - -Lyrics can be set to a melody automatically. Excess lyrics will be -dumped. Lyrics will not be set over rests. You can have melismata -either by setting a property melismaBusy, or by setting -automaticMelismas (which will set melismas during slurs and ties). If -you want a different order than first Music, then Lyrics, you must -precook a chord of staffs/lyrics and label those. Of course -@code{\rhythm} ignores any other rhythms in the piece. Hyphens and -extenders do not assume anything about lyric lengths, so they continue -to work. - -@mudelafile{lyric-combine.ly} - -@section Multiple notes - -Rests should not collide with beams, stems and noteheads. Rests may -be under beams. Rests should be move by integral number of spaces -inside the staff, and by half spaces outside. Notice that the half -and whole rests just outside the staff get ledger lines in different -cases. - -@mudelafile{rest-collision.ly} - -Normal collisions. We have support for polyphony, where the -middle voices are horizontally shifted. - -@mudelafile{collisions.ly} - -The number of stafflines of a staff can be set with the property -numberOfStaffLines. Ledger lines both on note heads and rests are -adjusted. Barlines also are adjusted. - - -@mudelafile{number-staff-lines.fly} - -@section Spacing - -In a limited number of cases, LilyPond corrects for optical spacing -effects. In this example, space for opposite pointed stems is adjusted - -@mudelafile{stem-spacing.sly} - -If there are accidentals in the music, we add space, but the space -between note and accidentals is less than between the notes with the -same value. Clef changes also get extra space, but not as much as -barlines. - - -Even if a line is very tightly spaced, there will still be room -between prefatory matter and the following notes. The space after the -prefatory is very rigid. In contrast, the space before the barline -must stretch like the space within the measure. - -Tight: - -@mudelafile{spacing-tight.ly} - -Natural: - -@mudelafile{spacing-natural.ly} - -Loose: - -@mudelafile{spacing-loose.ly} - -Adding a @code{Bar_engraver} to the LyricsVoice context makes sure that -lyrics don't collide with barlines. - -@mudelafile{lyrics-bar.ly} - -@section Global stuff - -Breaks can be encouraged and discouraged using @code{\break} and -@code{\nobreak}. They are abbrevs for @code{\penalty} commands. - -@mudelafile{break.ly} - - -Markings that are attached to (invisible) barlines are -delicate: the are attached to the rest of the score without the score -knowing it. Consequently, they fall over often. - -@mudelafile{bar-scripts.ly} - -Staff margins are also markings attached to barlines. They should be -left of the staff, and be centered vertically wrt the staff. They may -be on normal staffs, but also on compound staffs, like the PianoStaff - -@mudelafile{staff-margin.ly} - -Breathing signs, also used for phrasing, do normally not influence -global spacing -- only if space gets tight, notes are shifted to make -room for the breathing sign. Breathing signs break beams running -through their voice. In the following example, the notes in the first -two measures all have the same distance from each other: - -@mudelafile{breathing-sign.ly} - -Fonts are available in a default set of sizes: 11, 13, 16, 20, 23 and -26pt staffheight. Sizes of the text fonts and symbol fonts are made -to match the staff dimensions. - -@mudelafile[nofly]{size11.ly} - -@mudelafile[nofly]{size13.ly} - -@mudelafile[nofly]{size16.ly} - -@mudelafile[nofly]{size20.ly} - -@mudelafile[nofly]{size23.ly} - -@mudelafile[nofly]{size26.ly} - - -@section Clefs and Time Signatures - -The transparent clef should not occupy any space and with style -@code{fullSizeChanges}, the changing clef should be typeset in full -size. For octaviated clefs, the ``8'' should appear closely above or -below the clef respectively. The ``8'' is processed in a convoluted -way, so this is fragile as well. - -@mudelafile{clefs.ly} - -@ignore -@c the input file is too long and does not test for specific bugs -By default, time signatures are written with two numbers. With style -``C'', 4/4 and 2/2 are written with their corresponding symbols and -with style ``old'', 2/2, 3/2, 2/4, 3/4, 4/4, 6/4, 9/4, 4/8, 6/8 and -9/8 are typeset with symbols, all other signatures retain the default -layout. The style ``1'', gives single number signatures for all -signatures. -% -\mu delafile{time.fly} -@end ignore - -@bye diff --git a/Documentation/misc/NEWS-1.2~ b/Documentation/misc/NEWS-1.2~ deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/Documentation/pictures/lelie-icon.xpm b/Documentation/pictures/lelie-icon.xpm new file mode 100644 index 0000000000..0ad7f75dc1 --- /dev/null +++ b/Documentation/pictures/lelie-icon.xpm @@ -0,0 +1,141 @@ +/* XPM */ +static char *noname[] = { +/* width height ncolors chars_per_pixel */ +"50 71 63 2", +/* colors */ +"`` c #666664", +"`a c #F2F2F4", +"`b c #5E5E5C", +"`c c #EAEAEC", +"`d c #565654", +"`e c #E2E2E4", +"`f c #4E4E4C", +"`g c #DADADC", +"`h c #464644", +"`i c #D2D2D4", +"`j c #3E3E3C", +"`k c #CACACC", +"`l c #363634", +"`m c #C2C2C4", +"`n c #2E2E2C", +"`o c #BABABC", +"`p c #262624", +"`q c #B2B2B4", +"`r c #1E1E1C", +"`s c #AAAAAC", +"`t c #161614", +"`u c #A2A2A4", +"`v c #0E0E0C", +"`w c #9A9A9C", +"`x c #060604", +"`y c #929294", +"`z c #8A8A8C", +"a` c #828284", +"aa c #7A7A7C", +"ab c #727274", +"ac c #6A6A6C", +"ad c #626264", +"ae c #5A5A5C", +"af c #525254", +"ag c #4A4A4C", +"ah c #424244", +"ai c #3A3A3C", +"aj c #323234", +"ak c #2A2A2C", +"al c #FEFEFC", +"am c #222224", +"an c #F6F6F4", +"ao c #1A1A1C", +"ap c #EEEEEC", +"aq c #121214", +"ar c #E6E6E4", +"as c #0A0A0C", +"at c #DEDEDC", +"au c #D6D6D4", +"av c #CECECC", +"aw c #C6C6C4", +"ax c #BEBEBC", +"ay c #B6B6B4", +"az c #AEAEAC", +"b` c #A6A6A4", +"ba c #9E9E9C", +"bb c #969694", +"bc c #8E8E8C", +"bd c #868684", +"be c #7E7E7C", +"bf c #767674", +"bg c #6E6E6C", +"bh c #FAFAFC", +/* pixels */ +"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal", +"alalbhbhalalbhalalbhalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalalal", +"alalalbhbhalalbhalalalalalalalalalalalalalalalalalal`o`ya``s`wbhalalalalalalalalalalalalalalalalalal", +"bhalalalalalbhalalalalalalalalalalalalalalalalalal`a`malalalap`obb`malalalalal`cax`galalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalalalalalbcalbhalalalalalax`ialalal`gauav`u`ealalalalalalal", +"alalalalalalalbhalalalalalalalalalalalalalalalalawar`ialalalalalalalaxapalalbaacat`i`oalalalalalalal", +"alalbhalalalalbhalalalalalalalalalalalalalalalalazal`sbhalalalalalalalayalbh`eba`iapavalalalalalalal", +"albhalbhalalalalalalalalalalalalalalalalalalalal`oatalb``aalalalalalal`oanazazanbhayalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalalanawal`salalbaalalalalalalalazaa`cav`oalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalapawalalaranal`i`qalalalalalalbeayazbcbcalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalal`g`oapalalalalal`yalalalalal`gbbabbhapalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalal`sanalalalalalbdalalalalalbc`obbalalalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalapaaanalalalalal`qatan`ealax`sbbazalalalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalal`kab`oalalalalalau`uaw`salbb`ua`bcalalalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalalalayalalalalalalan`ea`axax`oba`oazaxaralalalalalalalalalalal", +"alalalalalalalalalalapbhalalalalalalalalalaybhalalalalan`s`sazav`gaz`qbdalalazalalalalalalalalalalal", +"alalalalalalalalalalax`u`aalalalalalalalalaraw`o`c`c`aaxaw`g`kav`sayb`ayalal`m`calalalalalalalalalal", +"alalalalalalalalalalal`c`sbhalalalalalalalalalal`c`jb`albh`yavapazay`w`ialalalay`aalalalalalalalalal", +"alalalalalalalalalalalalar`qbhalalalalalalalalalal`v`sav`abcaubbaw`u`salalalalalayapalalalalalalalal", +"alalalalalalalalalalalalal`i`kalalalalalalalalalal`l`way`uau`cazazazbc`q`ialalalal`galalalalalalalal", +"alalalalalalalalalalalalalalaw`galalalalalalan`i`m`hbe`q`oap`w`m`uax`ialax`salalalalalalalalalalalal", +"alalalalalalalalalalalalalalal`oatalalalbh`kbaadagad```oav`i`mb`ba`ualalal`i`oalalalalalalalalalalal", +"alalalalalalalalalalalalalalalanaz`aalanaz`nag`ian`w`k`iar`waw`o`o`ialalalalau`ialalalalalalalalalal", +"alalalalalalalalalalalalalalalalapba`c`zakac`aalau`calapaz`gbabb`qbhalalalalal`ualalalalalalalalalal", +"alalalalalalalalalalalalalalalalal`ibdambd`c`aalalalal`a`yax`kb``u`aalalalalal`e`kalalalalalalalalal", +"alalalalalalalalalalalalalalalalarbcajbf`q`kalalalalal`w`c`sbc`k`e`kalalalalalal`salalalalalalalalal", +"alalalalalalalalalalalalalalalalawaoaibbaw`kalalalalapbaaw`gb`baalaualalalalalal`salalalalalalalalal", +"alalalalalalalalalalalalalalal`cbgaq`y`q`o`ialalalal`wbh`sba`g`oalaralalalalalal`ualalalalalalalalal", +"alalalalalalalbhbhalalalalalalar`v`lbfazap`qapalal`gaz`k`e`y`u`galbhalalalalalalb`alalalalalalalalal", +"alalalalalalalalalalalalalalalbb`x`l`qayalap`u`aala`al`u`q`ebebhalbhalalalalalalb`alalalalalalalalal", +"alalalalalalalalalalalalalalal`gao`hayazalalapb``kax`iaubeaybaalalalalalalalalalbaalalalalalalalalal", +"alalalalalalalalalalalalalalalalbdahba`galalalatbcalbb`maxbeatalalalalalalalalalbaalalalalalalalalal", +"alalalalalalalalalalalalalalalalau`jb``calbhalal`k`oaw`zapbfalalalalanalalalalal`salalalalalalalalal", +"alalalalalalalalalalalalalalalal`aad`malalbbalalal`o`kbb`y`ialalalal`walalalalal`qalalalalalalalalal", +"alalalalalalalalalalalalalalalalalbebaalapbfalalalbhbb`c`dalalalalalagalalalalap`oalalalalalalalalal", +"alalalalalalalalalalalalalalalalalbb`ialalajalalalalap`w`walalalalaxaaalalalal`qalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalazalalalbf`aalalalalbaayanalalalbg`ealalalbh`qalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalaxalalalbebhalalal`c`s`saxalalal``alalalalaybhalalalalalalalalalal", +"alalalalalalalalalalalalalalalalal`oalalal`ealalalalbb`eaw`uawalalawalbhalataualalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalanalalalalalalalal`wb`alayb``malalal`sal`oalalalalalalalalalalalal", +"alalalalalalalalalalalalalalalalalalalal`galalalal`q`g`wauaraz`yalalaxapalbhalalalalalalalalalalalal", +"alalalalbhalalalalbhalalalalbhbhalalbhal`salalalal`waw`kay`kapb`al`k`galalalbhbhbhbhbhalalalalalalal", +"albhbhalbhalalalalbhalalalalalbhalalal`i`malalbhar`sbdal`q`oalalal`walalbhalalalalalbhalalalalalalal", +"bhalalalalalalalalalalalbhalalal`ialalanavalalalbcalbbat`g`qalbhar`qalalalalalalalalalbhbhbhbhbhbhal", +"alalalalbhbhbhalalbhbhalalalal`mbealbhalawalalalbd`iat`oaratalal`yalbhalalalalalalalalalalalalalbhal", +"alalbhalalalalbhalalalalbhbhal`najalal`aarbhal`s`eazalazazalal`cb`alalalbhbhbhbhbhalalalalalalalalal", +"bhalbhalalalalbhalalalalalalbbas`naralalalalal`yalazarauayalalbaa`albhalalalalalbhalalalalalalalbhal", +"alalalalalalalalalalbhalal`aaq`r`hbdalalalalaraz`m`aazan`mal`ebd`jalalalalalalalalbhbhbhbhbhbhalalal", +"alalbhbhbhalalbhbhalalalalaa`vah`d`d`calbhalbaal`qal`o`obhalbhbd`ray`i`gbhalalalalalalalalalbhalbhal", +"bhalalalalbhalalalalbhalal`v`t`lah```ualalalbaan`q`cavaxalalatbeai`hauaw`waz`kav`ialalalalalalalalal", +"bhalalalalbhalalalalal`aap`x`tahafbb`ybdalavat`sbh`sal`qalal`c`qafam`faab`axauav`i`s`oaualalbhalbhal", +"alalalalalalalanaxax`s`q`gasao`pbebabb`ubd`walb`al`oavapalalbhaybeagaq`n`sauaw`i`iapat`kayauapalalal", +"bhbhbhalalav`kazarauayay`sad`r`facae`mazaubgb``sbh`m`oalalalalavbbaeai`j`oav`g`oatau`c`g`a`eb`azanal", +"alalalat`o`e`mavayavauarawayaq`lbf`yb``e`zap`yawbd`qayalalalap`ibcad`j`jbb`i`gapal`cal`iatau`gar`o`c", +"alal`eavalbh`g`g`g`ialanaral`b`vabbd`u`ibd`e`ual`o`ea`bbbdbcb`arb````la``uap`i`cavapalarav`catav`c`q", +"al`eavar`aanar`gavatayavaranatasae`wbcawax`iaval`calalalalalalaybcaf`hbb`garan`g`c`g`i`eatauatau`oap", +"al`s`a`carau`capanal`gapanbhal`s`ragbc`e`k`walalalalalalal`cap`oa`bfbgarauauan`g`i`e`c`c`a`g`cauatal", +"al`e`qay`s`i`eanarau`matau`cauau`s`ta`bd`sawalbhalalbhalapatav`s`f`baxalanat`aananan`eawat`max`aalal", +"bhalbhawavbh`aavar`e`gawawau`k`i`c`i`h`d`y`ealalbhalalalalapauaxb`avan`carbhan`gau`aan`iax`ebhalalal", +"alalalalan`uawawal`g`e`e`oatavat`q`ganbb`babbhalalap`ubbb`bb`z`u`gaparbhbhalanaw`iavax`cbhalalalbhal", +"albhalbhalalbhanax`oaw`m`i`m`m`kbhalalalap`obaavalbhan`aan`aalalalalapaxawaw`oapanbhalalalalalalbhal", +"alalalalalalalalalalananbhanbhalalalalalalalan`gb``qawavaxau`m`o`o`s`eananalalalalalalalalalalalalal", +"alalalalalalbhbhbhalalalalalalalalbhalbhalalalalalalbhbhanbhalalalalalalalalalalalalalalalbhalalalal", +"albhalalalbhalalalalalalalalbhbhbhalalalbhalbhalalalalalalalbhalalalalalalalalalbhalalalbhalalalbhal", +"alalbhbhalalalalalbhalbhalalalalalalalalbhalalbhalalalalbhalalalbhalalbhbhbhalalbhbhbhalalbhalalbhal", +"albhalalalalalalbhalbhalbhalalalalbhalalalalbhalalalalalalalalbhalbhalalalalbhalalal`aalalalbhalalal", +"alalalalbhbhbhalalalalalalalalbhalbhalalalalalbhbhbhbhalalbhalalalbhalalalalalap`qbb`salalalalalbhal", +"alalalbhalalalalalalalalbhbhbhalalalbhalbhalalalalalalalbhalalalalalalalalalalae`uav`calalalbhalalal", +"bhbhalalalalalbhalbhalalalalalalalalbhalalbhalalalalbhalalalbhalalbhbhbhalalalalalaralalalalbhalbhal" +}; diff --git a/Documentation/pictures/lelie-logo.xpm b/Documentation/pictures/lelie-logo.xpm new file mode 100644 index 0000000000..15408fb2ef --- /dev/null +++ b/Documentation/pictures/lelie-logo.xpm @@ -0,0 +1,215 @@ +/* XPM */ +static char *noname[] = { +/* width height ncolors chars_per_pixel */ +"100 143 65 1", +/* colors */ +" c #ADADAD", +". c #A5A5A5", +"X c #9D9D9D", +"o c #959595", +"O c #8D8D8D", +"+ c #858585", +"@ c #7D7D7D", +"# c #757575", +"$ c #6D6D6D", +"% c #656565", +"& c #5D5D5D", +"* c #555555", +"= c #4D4D4D", +"- c #FCFCFC", +"; c #FAFAFA", +": c #454545", +"> c #F2F2F2", +", c #3D3D3D", +"< c #EAEAEA", +"1 c #353535", +"2 c #E2E2E2", +"3 c #2D2D2D", +"4 c #DADADA", +"5 c #252525", +"6 c #D2D2D2", +"7 c #1D1D1D", +"8 c #CACACA", +"9 c #151515", +"0 c #C2C2C2", +"q c #0D0D0D", +"w c #BABABA", +"e c #050505", +"r c #B2B2B2", +"t c #AAAAAA", +"y c #A2A2A2", +"u c #9A9A9A", +"i c #929292", +"p c #8A8A8A", +"a c #828282", +"s c #7A7A7A", +"d c #727272", +"f c #6A6A6A", +"g c #626262", +"h c #5A5A5A", +"j c #525252", +"k c #FDFDFD", +"l c #4A4A4A", +"z c #F5F5F5", +"x c #424242", +"c c #EDEDED", +"v c #3A3A3A", +"b c #E5E5E5", +"n c #323232", +"m c #DDDDDD", +"M c #2A2A2A", +"N c #D5D5D5", +"B c #222222", +"V c #CDCDCD", +"C c #1A1A1A", +"Z c #C5C5C5", +"A c #121212", +"S c #BDBDBD", +"D c #0A0A0A", +"F c #B5B5B5", +"G c #020202", +/* pixels */ +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkk;kkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkk;kkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkk;kkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.lexGGj*9jkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkhkkkkkkkkwhs+kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk6 kkkkkkkkkkkVeCkkkkkkkkkkkkrsspkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkOkkkkkkkkkkkkkk2G2kkkkkkkkkdkkkkekkkkkkkkkkkkkkkk", +"k;kkkk;kkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.Gkkkckkkkkkkkkkkk@kkkkkkkkskk:kkdokkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkw2rkkkkkkkkkkkkkkkkk1kkkkkkkdkGykuk@kkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkskk*kkkkkkkkkkkkkkkkrZkkkkkkGGtkm k%kkkkkkkkkkkkkkk", +"kkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkjkkk$kkkkkkkkkkkkkkkkk=kkkkkkwniw kk@kkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk&kkkk3kkkkkkkkkkkkkkkkw6kkkkkk>X6kk4rkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkakkkkk=kkkkkkkkkkkkkkkk=kkkw:vNkkkk$kkkkkkkkkkkkkkkk", +"kkkkkkkkkkk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk&k06kkkvckkkkkkkkkkkkkk+zkkqkkkkkk&kkkkkkkkkkkkkkkkk", +"kk;;kk;kkkkkkk;kk;kkkkkkkkkkkkkkkkkkkkkkkkkkkkkukkk+kkkk,kkkkkkkkkkkkkkk%kMkkkkk.ykkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkX8kky+kkkkk:kkkkkkkkkkkkkk$kGZk2Fwykkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkNikkkkk+mkkkknckkkkkkkkkkkkk@l*kZM@vGkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk4okkkkkkkkkkkkkGkkkkkkkkkkkkkZfikXkc$Ckkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkjkkkkkkkkkkkkkkGkkkkkkkkkkkkk9ry,>kktkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk% Zkkkkkkkkkkky.kkkkkkkkkkkXu6f$kkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkokpkknk*kh%kkkkkki4kkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkaikkkkkkkkkkkkkkkkkkkkkkk4rqZFskkk>kgk0>k%z44hk=kkkkkkk:kkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkk+ikkkkkkkkkkkkkkkkkkkkkkkkGhFFkkkk>Akskkvk*kxmZkkkkkkkkdkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkiikkkkkkkkkkkkkkkkkkkkkkk7D+0kkkk*FbNk,kkp.k*kkkkkkkkkzlkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkk>u.kkkkkkkkkkkkkkkkkkkkkkGGrF$;kkGkOkk7knkvkdkkkkkkkkkkzdkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkZoZkkkkkkkkkkkkkkkkkkkkkMM8$skk*zwkk:kkoNS@@kkkkkkkkkkkzMkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkSybkkkkkkkkkkkkkkkkkkkkfDO *kk=kwk>,kvk3kn>g$0kkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkku kkkkkkkkkkkkkkkkkkkV+G%uXkGkykk3kkfk+kjkkk*Mkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkO.kkkkkkkkkkkkkkk4o4k.G@&FS46;k4gkvkvk1gkkkkkG>kkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkiukkkkkkkkkkkkmSkSGG&GtrMFktkk9kk%kqkGckkkkkkGkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkcX kkkkkkkkkkukgGGG+;GMxZkOkkutkvk$k#xkkkkkkkk5kkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkNoVkkkkkkktjdGGsikkkGGVk+kmkBkkdkMkGhkkkkkkkkkjkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk X>kkyakk;;kyk7kkxkGkGykkkkkkkkkkkMkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkphk6k9Gqx1kkkkNSkkkkkSk,kk:k2skGmkkkkkkkkkkkb&kkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk+ukGG&=kkkkkkkkkkkkzakkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk.;G6i>kkkkkkkkkk+tkkjkh;kGpkkskkkkkkkkkkkkwrkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk6kG77n:VOk#kkkkkkkkkkkGkkskkqkjx6k; kkkkkkkkkkkkk&kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk lGGxX,koykkkkkkkkkkkgbkk3k+tkGkkk$kkkkkkkkkkkkkk3kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk6kGGGFXdkbyukkkkkkkkkkCkkf;kGk41kkkpkkkkkkkkkkkkk=kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk4rGG1nyjm%kkkOakkkkkkDkkknkk1koGtkkkkokkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkk ,GC,5 cZ6kkkkO@kkkk.gkkONk1kkGZkkkk+kkkkkkkkkkkkkk=kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkOyGG=l#;%2kkkkkOakkkGkkknkkGkkCfkkkk;kkkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk4GG:*OV@Zkkkkkkpiktpkk 8k56kv9;kkkkkkkkkkkkkkkkkkk,kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkcGG#s>ykkkkkkk>obGkkk7kkGkkq8kkkkkkkkkkkkkkkkkkkk7kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2CGp*0rkkkkkkkk .akkurkp+kbqokkkkkkkkkkkkkkkkkkkkjkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkm#Gpd;bkkkkkkkkktukkDkkGkkxu>kkkkkkkkkkkkkkkkkkkk=kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkNGgCkFkkkkkkkkkkpXmik<,kkGSkkkkkkkkkkkkkkkkkkkkk&kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkktyGtVkkkkNkkkkkkkovkkGkkdd4kkkkkkkkNkkkkkkkkkkkkfkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkSGk.kkkkGkkkkkkk;o0kGkk9rkkkkkkkkkGkkkkkkkkkkkw8kkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkbAhkkkkkGkkkkkkkk2t3wkwx;kkkkkkkkkG2kkkkkkkkkkMkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk83MkkkkFGkkkkkkkkkuokkA*kkkkkkkkkkG&kkkkkkkkkkhkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkA=kkkkkGVkkkkkkkkkd.kGbkkkkkkkkkkGZkkkkkkkkk$;kkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk5ykkkkkGGkkkkkkkkkkfdnzkkkkkkkkkaGkkkkkkkkkkgkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkjkkkkkkrGkkkkkkkkkkkdikkkkkkkkkkGDkkkkkkkkkkkkkkkkkkN&wukkkkkkkkkkkkkkGkkkkkkkkObkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkhkkkkkkkkkkkkkkkkkkGkkgkk9ykkkkkkpkkkkkkk2.kkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkykkkkkkkkkkkkkkkkk2gkjzkXkyskkkkkkkkkbkkkhkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkvkkxkk&k4@#kkkkkkkm5kk*kkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk7kkgkkfk&koZkkkkkk%kk;0kkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2kkkkkkkkkf8k1kktNkjkiXkkkkkhkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk:kkkkkkkkkekk7kk$kkhk@akkkkfkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkobkkkkkkkk4#kr+kkjkOkkXhkkk ykkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk5kkkkkkkkkCkkGkk6Zk%kkkkkkk7kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkik kkkkkkkkCkkGkkgkk%kkkkkk8pkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkpkskkkkkkkgbkOrkkgkV8kkkkkk9kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk2NkkkkkkkGkkGkkNXkhkkkkkkk3kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkGkkkkkkkukkkkkkk4&kkfkk$kk$kkkkkk$kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkFGkkkkkkk+kkkkkkkqkkFSkkfkz kkkkkkqkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkGGckkkkkkukkkkkkkDkkjkk>ykdkkkkkkk7kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkhGGdkkkkkNSkkkkkk=4kkjkk*kk*kkkkkkk%kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkGGCGkkkkkkkkkkkkkGkka;kk=kk&kkkkkawikkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkkAGG%Gkkkkkkkkkkkk4&kkjkkkukXckkkkmn$.kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkk>G3Gnv%kkkkkkkkkkkCkkk&kk%kk=kkkkkkg3Xkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkkGGe91gGkkkkkkkkkkkCkkpkkkjkk$kkkbS.99@kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkk GGA$B%pskkkkkkkkkd4kk=kkkdkVZkkkkbbdG3kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkkGGAG$Gi$v;kkkkkkkk7kk>skk+kk%kkkkkk0OG,okkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkktGBqCaha9dXkkkkkkkk&kkhkkkhkk$kkkkk<#BvG9mpsfN>kkkkkkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkGGGeD=,Chtswkkkkkk1kkkjkkkskk+kkkk6mX@:BC:kNrm3$fwitkkkkkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkGGGj5*gl$12=kkkkkk1kkNokkozkskkkkkk0y&%1GtFkykkF$kckdpftkkkkkkkkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkkkkkkkkkGAG5en#Dwyk+7kkkkZ kkjkkkxkkgkkkkkkkF hCnGlgO.xz>4b+dyikkkkkkkkkkkk", +"kkkkkkkkkkkkkkkkkkbot&h akGGG5GG*@syi06.Gkkhkkrwkk bkF2kkkkkkkwp +*=DGGjokkSjNXk tkkkk2ud$2kkkkkkkkk", +"kkkkkkkkkkkkkkk6p3$48wNckknGG=*MfNSt.a*c#*Akkk3kkk*kk&kkkkkkkkkX@loD=Ge$apykkkNkkkm2mVVkkk8sXkkkkkkk", +"kkkkkkkkkkkkkXi4k>0NsZk+sSrGB,Cs,lMAX46fkkGlak&kkk&kk&kkkkkkkkkpt$$,%MGh%>kkkbFrwm2k4>kbkkmkN9#kkkkk", +"kkkkkkkkkkNvy6%SkkkbN8awiSkGeDBpl0Fdc0.k0Si;8G&kk4VkkS2uk", +"kkkkkk%zkkkk<800840kkkkkkkkkFGDG:O aOOkVoa.k%kkkbSk>Gn&GGBnD9uVwkzkkNZ4kkk6VSkkkGGCps&$k$gkDk4k5kkkgkk>kkkkkkkkkkkz0bd#vGvbFkkkk4mkkZNkkkkt6kkzrkkFpNkk>owbkkkrNkmw;y mk", +"kkk$kkkbkykkAkkkkkkkkkkkkkkkkkkkwoZ+$3orkkkkkk4 Zkkkkk.0kkkbkk4kbukkk", +"kkkhkk8Nkkb8>zckkckkbFVkkkkkGBGOj%r;#k2+kkkkkkkkkkkkkkkyww02k.wkkkk", +"kkkXscihna6kwkbzkkk0iVz0y8kckVykkGC7oZGky8,kkkkkkkkkkkkkkwZkkFuh=jll3kkkkkkkk<2kkkkkkkkVw;k ;hckkkkk", +"kkkkklkkk>wr6kkk>opkk.0k2kFkO;ZbkkqGxdM8Fpkkkkkkkkkkkkkkkkk FVkNn%F5kkkkkk2tcckkkk2kVtiukSwyokkkkkkk", +"kkkkkkXOkkkkkkkyVkkkkVSZZ kFNF48Nkk8Gl5FiakkkkkkkkkkkkkkkkkV0 dpka&kkkkkkkkkkkkwyF4kkzzkruykkkkkkkkk", +"kkkkkkkzsykkkNpkkm4wF2w2N8 $(outdir)/index.html diff --git a/Documentation/programmer/feta20.sty b/Documentation/programmer/feta20.sty new file mode 100644 index 0000000000..0dbfcf90cc --- /dev/null +++ b/Documentation/programmer/feta20.sty @@ -0,0 +1,146 @@ +% Creator: mf-to-table.py version 0.7 +% Automatically generated on +% Do not edit +% input from out/feta20.log +% name +% rests +\fetdef\wholerest{0} +\fetdef\halfrest{1} +\fetdef\outsidewholerest{2} +\fetdef\outsidehalfrest{3} +\fetdef\breverest{4} +\fetdef\longarest{5} +\fetdef\multirest{6} +\fetdef\quartrest{7} +\fetdef\eighthrest{8} +\fetdef\sixteenthrest{9} +\fetdef\thirtysecondrest{10} +\fetdef\sixtyfourthrest{11} +\fetdef\hundredtwentyeighthrest{12} + +% accidentals +\fetdef\sharp{13} +\fetdef\natural{14} +\fetdef\flat{15} +\fetdef\flatflat{16} +\fetdef\sharpsharp{17} +\fetdef\rightparen{18} +\fetdef\leftparen{19} + +% dots +\fetdef\dot{20} +\fetdef\repeatcolon{21} + +% balls +\fetdef\brevisball{22} +\fetdef\brevisledger{23} +\fetdef\longaball{24} +\fetdef\longaledger{25} +\fetdef\wholeball{26} +\fetdef\wholeledger{27} +\fetdef\halfball{28} +\fetdef\halfledger{29} +\fetdef\quartball{30} +\fetdef\quartledger{31} + +% scripts +\fetdef\ufermata{32} +\fetdef\dfermata{33} +\fetdef\thumb{34} +\fetdef\sforzatoaccent{35} +\fetdef\staccato{36} +\fetdef\ustaccatissimo{37} +\fetdef\dstaccatissimo{38} +\fetdef\tenuto{39} +\fetdef\umarcato{40} +\fetdef\dmarcato{41} +\fetdef\ouvert{42} +\fetdef\plusstop{43} +\fetdef\upbow{44} +\fetdef\downbow{45} +\fetdef\reverseturn{46} +\fetdef\turn{47} +\fetdef\trill{48} +\fetdef\upedalheel{49} +\fetdef\dpedalheel{50} +\fetdef\upedaltoe{51} +\fetdef\dpedaltoe{52} +\fetdef\flageolet{53} +\fetdef\trilelement{54} +\fetdef\prall{55} +\fetdef\mordent{56} +\fetdef\prallprall{57} +\fetdef\prallmordent{58} +\fetdef\upprall{59} +\fetdef\downprall{60} +\fetdef\accDiscant{61} +\fetdef\accDiscantF{62} +\fetdef\accDiscantEh{63} +\fetdef\accDiscantE{64} +\fetdef\accDiscantFE{65} +\fetdef\accDiscantFEh{66} +\fetdef\accDiscantEE{67} +\fetdef\accDiscantFEE{68} +\fetdef\accDiscantEEE{69} +\fetdef\accDiscantFEEE{70} +\fetdef\accDiscantS{71} +\fetdef\accDiscantFS{72} +\fetdef\accDiscantES{73} +\fetdef\accDiscantEhS{74} +\fetdef\accDiscantFES{75} +\fetdef\accDiscantFEhS{76} +\fetdef\accDiscantEES{77} +\fetdef\accDiscantFEES{78} +\fetdef\accDiscantEEES{79} +\fetdef\accDiscantFEEES{80} +\fetdef\accDiscantSS{81} +\fetdef\accDiscantESS{82} +\fetdef\accDiscantEESS{83} +\fetdef\accDiscantEEESS{84} +\fetdef\accFreebass{85} +\fetdef\accFreebassF{86} +\fetdef\accFreebassE{87} +\fetdef\accFreebassFE{88} +\fetdef\accStdbass{89} +\fetdef\accStdbassM{90} +\fetdef\accStdbassBp{91} +\fetdef\accStdbassT{92} +\fetdef\accStdbassTp{93} +\fetdef\accBayanbass{94} +\fetdef\accBayanbassT{95} +\fetdef\accBayanbassE{96} +\fetdef\accBayanbassTE{97} +\fetdef\accBayanbassEE{98} +\fetdef\accBayanbassTEE{99} +\fetdef\accSB{100} +\fetdef\accBB{101} +\fetdef\accOldEE{102} +\fetdef\accOldEES{103} + +% flags +\fetdef\eighthflag{104} +\fetdef\sixteenthflag{105} +\fetdef\thirtysecondflag{106} +\fetdef\sixtyfourthflag{107} +\fetdef\deighthflag{108} +\fetdef\dsixteenthflag{109} +\fetdef\dthirtysecondflag{110} +\fetdef\dsixtyfourthflag{111} + +% clefs +\fetdef\altoclef{112} +\fetdef\caltoclef{113} +\fetdef\bassclef{114} +\fetdef\cbassclef{115} +\fetdef\trebleclef{116} +\fetdef\ctrebleclef{117} + +% timesig +\fetdef\fourfourmeter{118} +\fetdef\allabreve{119} +\fetdef\oldfourfourmeter{120} +\fetdef\oldallabreve{121} +\fetdef\oldthreetwometer{122} +\fetdef\oldsixfourmeter{123} +\fetdef\oldninefourmeter{124} + diff --git a/Documentation/programmer/fonts.doc b/Documentation/programmer/fonts.doc new file mode 100644 index 0000000000..287dde49b1 --- /dev/null +++ b/Documentation/programmer/fonts.doc @@ -0,0 +1,330 @@ + + % -*-LaTeX-*- + +\documentclass{article} +\def\kdots{,\ldots,} +\title{Not the Font-En-Tja font} +\author{HWN \& JCN} +\def\preMudelaExample{} +\def\postMudelaExample{} +\begin{document} +\maketitle + + +\section{Introduction} + +This document are some design notes of the Feta font, and other +symbols related to LilyPond. Feta (not an abbreviation of +Font-En-Tja) is a font of music symbols. All MetaFont sources are +original. The symbols are modelled after various editions of music, +notably \begin{itemize} \item B\"arenreiter \item Hofmeister \item +Breitkopf \item Durand \& C'ie \end{itemize} + +The best references on Music engraving are Wanske\cite{wanske} and +Ross\cite{ross} some of their insights were used. Although it is a +matter of taste, I'd say that B\"arenreiter has the finest typography +of all. + + +\section{Bezier curves for slurs} + +Objective: slurs in music are curved objects designating that notes +should fluently bound. They are drawn as smooth curves, with their +center thicker and the endings tapered. + +There are some variants: the simplest slur shape only has the width as +parameter. Then we give some suggestions for tuning the shapes. The +simple slur algorithm is used for drawing ties as well. + + + +\subsection{Simple slurs} + +Long slurs are flat, whereas short slurs look like small circle arcs. +Details are given in Wanske\cite{ross} and Ross\cite{wanske}. The +shape of a slur can be given as a Bezier curve with four control +points: + +\begin{eqnarray*} + B(t) &=& (1-t)^3c_1 +3(1-t)^2tc_2 + 3(1-t)t^2c_3 + t^3c_4. +\end{eqnarray*} + +We will assume that the slur connects two notes of the same +pitch. Different slurs can be created by rotating the derived shape. +We will also assume that the slur has a vertical axis of symmetry +through its center. The left point will be the origin. So we have +the following equations for the control points $c_1\kdots c_4$. + +\begin{eqnarray*} +c_1&=& (0,0)\\ +c_2&=& (i, h)\\ +c_3&=& (b-i, h)\\ +c_4&=& (b, 0) +\end{eqnarray*} + +The quantity $b$ is given, it is the width of the slur. The +conditions on the shape of the slur for small and large $b$ transform +to +\begin{eqnarray*} + h \to h_{\infty} , &&\quad b \to \infty\\ + h \approx r_{0} b, &&\quad b \to 0. +\end{eqnarray*} +To tackle this, we will assume that $h = F(b)$, for some kind of +$F(\cdot)$. One function that satisfies the above conditions is +$$ +F(b) = h_{\infty} \frac{2}{\pi} \arctan \left( \frac{\pi r_0}{2 +h_{\infty}} b \right). +$$ + +For satisfying results we choose $h_{\infty} = 2\cdot \texttt{interline}$ +and $r_0 = \frac 13$. + +\subsection{Height correction} + +Aside from being a smooth curve, slurs should avoid crossing +enclosed notes and their stems. + +An easy way to achieve this is to extend the slur's height, +so that the slur will curve just above any disturbing notes. + +The parameter $i$ determines the flatness of the curve. Satisfying +results have been obtained with $i = h$. + +The formula can be generalised to allow for corrections in the shape, +\begin{eqnarray*} +c_1&=& (0,0)\\ +c_2&=& (i', h')\\ +c_3&=& (b-i', h')\\ +c_4&=& (b, 0) +\end{eqnarray*} +Where +$$ +i' = h(b) (1 + i_{corr}), \quad h' = h(b) (1 + h_{corr}). +$$ + +The default values for these corrections are $0$. A $h_{corr}$ that is +negative, makes the curve flatter in the center. A $h_{corr}$ that is +positive make the curve higher. + +At every encompassed note's x position the difference $\delta _y$ +between the slur's height and the note is calculated. The greatest +$\delta _y$ is used to calculate $h_{corr}$ is by lineair extrapolation. + +However, this simple method produces satisfactory results only for +small and symmetric disturbances. + + +\subsection{Tangent method correction} + +A somewhat more elaborate\footnote{While staying in the realm +of empiric computer science} way of having a slur avoid +disturbing notes is by first defining the slur's ideal shape +and then using the height correction. The ideal shape of a +slur can be guessed by calculating the tangents of the disturbing +notes: +% a picture wouldn't hurt... +\begin{eqnarray*} + y_{disturb,l} &=& \rm{rc}_l x\\ + y_{disturb,r} &=& \rm{rc}_r + c_{3,x}, +\end{eqnarray*} +where +\begin{eqnarray*} + \rm{rc}_l &=& \frac{y_{disturb,l} - y_{encompass,1}} + {x_{disturb,l} - x_{encompass,1}}\dot x\\ + \rm{rc}_r &=& \frac{y_{encompass,n} - y_{disturb,r}} + {x_{encompass,n} - x_{disturb,r}} \dot x + c_{3,x}. +\end{eqnarray*} + +We assume that having the control points $c_2$ and $c_3$ located +on tangent$_1$ and tangent$_2$ resp. +% t: tangent +\begin{eqnarray*} + y_{tangent,l} &=& \alpha \rm{rc}_l x\\ + y_{tangent,r} &=& \alpha \rm{rc}_r + c_{3,x}. +\end{eqnarray*} + +Beautiful slurs have rather strong curvature at the extreme +control points. That's why we'll have $\alpha > 1$. +Satisfactory resulsts have been obtained with +$$ + \alpha \approx 2.4. +$$ + +The positions of control points $c_2$ and $c_3$ are obtained +by solving with the height-line +\begin{eqnarray*} + y_h &=& \rm{rc}_h + c_h. +\end{eqnarray*} + +The top-line runs through the points disturb$_{left}$ and +disturb$_{right}$. In the case that +$$ +z_{disturb,l} = z_{disturb,r}, +$$ +we'll have +$$ + \angle(y_{tangent,l},y_h) = \angle(y_{tangent,r},y_h). +$$ + + + +\section{Sizes} + +Traditional engraving uses a set of 9 standardised sizes for Staffs +(running from 0 to 8). + +We have tried to measure these (helped by a magnifying glass), and +found the staffsizes in table~\ref{fonts:staff-size}. One should note that +these are estimates, so I think there could be a measuring error of ~ +.5 pt. Moreover [Ross] states that not all engravers use exactly +those sizes. + +\begin{table}[h] + \begin{center} + \begin{tabular}{lll} +Staffsize &Numbers &Name\\ +\hline\\ +26.2pt &No. 0\\ +22.6pt &No. 1 &Giant/English\\ +21.3pt &No. 2 &Giant/English\\ +19.9pt &No. 3 &Regular, Ordinary, Common\\ +19.1pt &No. 4 &Peter\\ +17.1pt &No. 5 &Large middle\\ +15.9pt &No. 6 &Small middle\\ +13.7pt &No. 7 &Cadenza\\ +11.1pt &No. 8 &Pearl\\ + \end{tabular} + \caption{Foo} + \label{fonts:staff-size} + \end{center} +\end{table} + + + + +\section{Beams} + +\subsection{Slope} + +Traditionally, beam slopes are computed by following a large and hairy +set of rules. Some of these are talked-about in Wanske, a more +recipy-like description can be found in Ross. + +There are some problems when trying to follow these rules: +\begin{itemize} + +\item the set is not complete + +\item they are not formulated as a general rule with exceptions, but +rather as a huge case of individual rules\cite{ross} + +\item in some cases, the result is wrong or ugly (or both) + +\item they try to solve a couple of problems at a time (e.g. Ross +handles ideal slope and slope-quantisation as a paired problem) +\end{itemize} +Reading Ross it is clear that the rules presented there are certainly +not the ultimate idea of what beam(slope)s should look like, but +rather a (very much) simplified hands-on recipy for a human engraver. + +There are good reasons not to follow those rules: + +\begin{itemize} +\item One cannot expect a human engraver to solve least-squares +problems for every beam + +\item A human engravers will allways trust themselves in judging the +outcome of the applied recipy. If, in a complicated case, the result +"doesn't look good", they will ignore the rules and draw their own +beams, based on experience. + +\item The exact rules probably don't "really exist" but in the minds + of good engravers, in the form of experience +\end{itemize} + +We'll propose to do a least-squares solve. This seems to be the best +way to calculate the slope for a computerised engraver such as Lily. + +It would be nice to have some rules to catch and handle "ugly" cases, +though. In general, the slope of the beam should mirror the pitches +of the notes. If this can't be done because there simply is no +uniform trend, it would probably be best to set the slope to zero. + + +\subsection{Quantising} + +The beams should be prevented to conflict with the stafflines, +especially at small slopes. Traditionally, poor printing techniques +imposed rather strict rules for quantisation. In modern (post 1955) +music printing we see that quality has improved substantially and +obsoleted the technical justification for following some of these +strict rules, notably the avoiding of so-called wedges. + + +\subsection{Thickness and spacing} + +The spacing of double and triple beams (sixteenth and thirtysecond beams) +is the same, quadruple and quintuple (thirtyfourth and hundredtwentyeighth +beams) is wider. +All beams are equally thick. Using the layout of triple beams and the +beam-thickness $bt$ we can calculate the inter-beam spacing $ib$. + +Three beams span two interlines, including stafflines: +\begin{eqnarray*} + 2 ib + bt &=& 2 il\\ + ib &=& (2 il - bt) / 2 +\end{eqnarray*} + +We choose +\begin{eqnarray*} + bt &=& 0.48(il - st) +\end{eqnarray*} + +\subsubsection{Quadruple beams} + +If we have more than three beams they must open-up +in order to not collide with staff lines. The only valid +position that remains is for the upper beam to hang. + +\begin{eqnarray*} + 3 ib_{4+} + bt &=& 3 il\\ + ib_{4+} &=& (3 il - bt) / 3 +\end{eqnarray*} + + +\section{Layout of the source files} + +The main font (with the fixed size music glyphs) uses a the \TeX\ +logfile as a communication device. Use the specialised macros to +create and export glyphs. + +\bibliographystyle{plain} +\bibliography{engraving} + + + +\end{document} + +\begin{verbatim} +Paul Terry writes: + +Ross states that the dies (the stamps to make the symbols) come in +12 different sizes. + +>Can you tell me how big rastrals are? + +According to the Score manual: + + Rastral Size Height in millimetres + + 0 9 mm + 1 8 mm + 2 7.5 mm + 3 7 mm + 4 6.5 mm + 5 6 mm + 6 5.5 mm + +I must say, despite having been a music setter for many years, I had to +look these up - none of the publishers I work for deal in Rastral sizes +these days (they all use millimetres). diff --git a/Documentation/programmer/hacking.texi b/Documentation/programmer/hacking.texi new file mode 100644 index 0000000000..233c800216 --- /dev/null +++ b/Documentation/programmer/hacking.texi @@ -0,0 +1,851 @@ +\input texinfo @c -*-texinfo-*- +@setfilename internals.info +@settitle LilyPond internals + +@node Top, LilyPond internals, (dir), (dir) +@top + + +@menu +* LilyPond internals:: +* Overview:: +* mudela:: +* Request_engraver:: +* Graphic elements:: +* Score elements:: +* Items:: +* Spanners:: +* Future work:: +* Coding standards:: +* Making patches:: + +@end menu + +@node LilyPond internals, , Top, Top +@menu +* Overview:: Overview +* mudela:: mudela +* Request_engraver:: Request_engraver +@end menu + + +@chapter Getting involved + +Please help us make LilyPond a better program. You can help LilyPond in +several ways. Not all tasks requiring programming or understanding the +full source code. You can write to the mailing list +(@email{gnu-music-discuss@@gnu.org} for more information) + +@unnumberedsubsec Users + +Mutopia needs your help. The mutopia project is a collection of public +domain sheet music. You can help the project by entering music and +submitting. Point your browser to the +@uref{http://sca.uwaterloo.ca/Mutopia, Mutopia webpage} + +@unnumberedsubsec Font designers + +Our set of glyphs (the Feta font) is far from complete. If you know a +little MetaFont you can contribute a glyph + +@unnumberedsubsec Writers + +The documentation of LilyPond and related utilities needs a lot of work. + +@unnumberedsubsec Translators + +LilyPond is completely ready for internationalized messages, but there +are only three translations so far. + +@unnumberedsubsec Hackers + + +There are lots of possibilities of improving the program itself. There are +both small projects and big ones. Most of them are listed in the TODO +file. A interesting and very big project is writing a GUI frontend to +LilyPond. + + + +@chapter LilyPond internals + + +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. + +@node Overview, mudela, Top, Top +@section 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. + +@table @samp + +@item 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. + +@item 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). + +@item Prebreaking + +Breakable stuff (eg. clefs and bars) are copied into pre and +postbreaks. + +@item 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), + +@item Break calculation: + +The lines and horizontal positions of the columns are determined. + +@item 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. + +@item Postprocesing: + +Some items and all spanners need computation after the Paper_column +positions are determined. Examples: slurs, vertical positions of +staffs. + +@item Output paper + +@end table + +@node mudela, Request_engraver, Overview, Top +@section 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' + +@table @samp +@item @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. +@item @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. +@item @code{Rest_req} + Typeset a rest. +@item @code{Span_req} + This type of request typically results in the creation of a @code{Spanner} +@item @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. +@item @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. +@end table + +@node Request_engraver, , mudela, Top +@section 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 + +@example + + \type Staff < % chord + @{ \meter 2/4; [c8 c8] @} + @{\meter 2/4; [e8 e8] @} + > + +@end example + +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. + +@unnumberedsubsec example: + +@example + + c4 + +@end example + +produces: + +@example + + Note_request (duration 1/4) + Stem_request (duration 1/4) + +@end example + +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}. + + + +@node Graphic elements, , , Top +@section Graphic elements + + +Music notation is composed of a sets of interrelated glyphs. In +Lilypond every glyph usually is represented by one object, a so-called +Graphic Object. The primary relations between graphic objects involve +positions: + +@itemize +@item consecutive notes are printed left to right, grouped in a staff +@item simultaneous notes are horizontally aligned (internally grouped in +a paper column). +@item the staccato mark is horizontally centered on the note it applies +to. +@end itemize + +The abstract encoding of such relations is done with the concept +@dfn{reference point}. The reference point (in X direction) of the +staccato mark is the note it applies to. The (X) position of the +staccato mark is stored relative to the position of the note head. This +means that the staccato will always maintain a fixed offset wrt to the +note head, whereever the head is moved to. + +In the same vein, all notes on a staff have their Y positions stored +relative to an abstract object called Axis_group_spanner. If the +Axis_group_spanner of one staff is moved, the absolute Y positions of +all objects in that spanner change along, in effect causing the staff +and all its contents to move as a whole. + +Each graphic object stores a pointer and an relative offset for each +direction: one for the X-axis, one for the Y-axis. For example, the X +parent of a Note_head usually is a Note_column. The X parent of a +Note_column usually is either a Collision or a Paper_column. The X +parent of a Collision usually is a Paper_column. If the Collision +moves, all Note_heads that have that Collision as parent also move, but +the absolute position of the Paper_column does not change. + +To build a graphical score with Graphic_elements, conceptually, one +needs to have one Root object (in Lilypond: Line_of_score), and +recursively attach objects to the Root. However, due to the nature +of the context selection mechanisms, it turns out to be more +advantageous to construct the tree the other way around: first small +trees (note heads, barlines etc.) are created, and these are +subsequently composed into larger trees, which are finally hung on a +Paper_column (in X direction) or Line_of_score (in Y direction). + +The structure of the X,Y parent relations are determined by the +engravers and notation contexts: + +The most important X-axis parent relation depends on the timing: notes +that come earlier are attached to Paper_column that will be positioned +more to the left. + +The most important Y-axis relation depends on containment of contexts: +notes (created in a Thread or Voice context) are put in the staff where +the originating context lives in. + +Graphical_axis_groups are special graphic objects, that are designed to +function as a parent. The size of a Graphical_axis_groups group is the +union of its children. + +@node Score elements, , , Top + +Besides relative positions there are lots of other relations between +elements. Lilypond does not contain other specialized relation +management (Like the relative positioning code). In stead, objects can +be connected through dependencies, which sets the order in which objects +are to be processed. + +Example: the direction of a beamed stem should equal the direction of +the beam. When the stem is a added to the beam, a dependency on the +beam is set in the stem: this means that @code{Beam::do_pre_processing +()} (which does various direction related things) will be called before +@code{Stem::do_pre_processing ()}. + +The code that manages dependencies resides in the class +@code{Score_element}, a derived class of @code{Graphical_element}. The +bulk of the code handles line breaking related issues. + +To sketch the problems with line breaking: suppose a slur spans a line +break, +@example + +c4( c'''' c | \break d d )d + +@end example +In this case, the slur will appear as two parts, the first part spanning +the first three notes (the @code{c}s), the second spanning the last +three (the @code{d}s). Within Lilypond this is modeled as breaking the +slur in parts: from the Original slur, two new clones of the old slur +are made. Initially both clones depend on the six notes. After the +hairy code in Score_element, Spanner and Item which does substitutions +in sets of dependencies, the first clone depends on the first three +notes, the second on the last three. + +The major derived classes of Score_element are Item and Spanner. +An item has one horizontal position. A spanner hangs on two items. + +@node Items, , , Top +@section Items + + + +An item is a score element that is associated with only one +Paper_column. Examples are note heads, clefs, sup and superscripts, etc. +Item is a derived class of Score_element. + +The shape of an item is known before the break calculations, and line +spacing depends on the size of items: very wide items need more space +than very small ones. + +An additional complication is the behavior of items at linebreaks. For +example, when you do a time signature change, you get only one symbol. +If it occurs at a linebreak, the new time signature must be printed both +before and after the linebreak. Other `breakable symbols' such as +clefs, and bar lines also exhibit this behavior. + +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. To support this, +breakable items are generated in the three versions: original +(unbroken), left (before line break) and right (after line break). +During the line spacing, these versions are used to try how the spacing +of a line works out. + +Once the definitive spacing is determined, dependencies (and various +other pointers) are substituted such that all dependencies point at the +active items: either they point at the original, or they point at left +and right. + +@node Spanners, , , Top +@section Spanners + +Spanners are symbols that are of variable shape, eg. Slurs, beams, etc. +Spanners is a derived class of Score_element. + +The final shape can only be determined after the line breaking process. +All spanners are spanned on two items, called the left and right +boundary item. The X reference point is the left boundary item. + + +@node Future work, , , Top +@section Future work + +There are plans to unify Spanner and Item, so there will no longer be +such a clear distinction between the two. Right now, Score_elements are +always either Item or either Spanner. + +Most of the properties of a graphic object are now member variables of +the classes involved. To offer configurability, we want to move these +variables to scheme (GUILE) variables, and no longer use C++ code to +calculate them, but use Scheme functions. + +@node Coding standards, , , Top + +@chapter CodingStyle - standards while programming for GNU +LilyPond + +Functions and methods do not return errorcodes. + + +@unnumberedsubsec Languages + +C++ and Python are preferred. Perl is not. Python code should use an +indent of 8, using TAB characters. + +@unnumberedsubsec Filenames + +Definitions of classes that are only accessed via pointers +(*) or references (&) shall not be included as include files. + +filenames + +@example + ".hh" Include files + ".cc" Implementation files + ".icc" Inline definition files + ".tcc" non inline Template defs +@end example + +in emacs: + +@example + (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)) +@end example + + +The class Class_name_abbreviation is coded in @file{class-name-abbr.*} + +@unnumberedsubsec Indentation + +Standard GNU coding style is used. In emacs: + +@example + (add-hook 'c++-mode-hook + '(lambda() (c-set-style "gnu") + ) + ) +@end example + +If you like using font-lock, you can also add this to your @file{.emacs}: + +@example + (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)) + )) +@end example + +@unnumberedsubsec Classes and Types + +@example + This_is_a_class +@end example + +@unnumberedsubsec Members + +@example + Class::member () + Type Class::member_type_ + Type Class::member_type () +@end example + +the @code{type} is a Hungarian notation postfix for @code{Type}. See below + +@unnumberedsubsec 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 ()}. + +@unnumberedsubsec 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. + +@unnumberedsubsec Comments + +The source is commented in the DOC++ style. Check out doc++ at +@uref{http://www.zib.de/Visual/software/doc++/index.html} + +@example + + /* + 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 + @} + @}; + +@end example + + +Unfortunately most of the code isn't really documented that good. + +@unnumberedsubsec Members (2) + +Standard methods: + +@example + + ///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 (..) + +@end example + +@unnumberedsubsec Constructor + +Every class should have a default constructor. + +Don't use non-default constructors if this can be avoided: + +@example + + Foo f(1) + +@end example + +is less readable than + +@example + + Foo f; + f.x = 1 + +@end example + +or + +@example + + Foo f(Foo_convert::int_to_foo (1)) + +@end example + +@unnumberedsec Hungarian notation naming convention + +Proposed is a naming convention derived from the so-called +@emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all +uppercase, with the parts of the names separated by underscores. + +The hungarian notation is to be used when variables are not declared +near usage (mostly in member variables and functions). + +@unnumberedsubsec Types + +@table @samp +@item @code{byte} + unsigned char. (The postfix _by is ambiguous) +@item @code{b} + bool +@item @code{bi} + bit +@item @code{ch} + char +@item @code{f} + float +@item @code{i} + signed integer +@item @code{str} + string class +@item @code{sz} + Zero terminated c string +@item @code{u} + unsigned integer +@end table + +@unnumberedsubsec User defined types + +@example + + /** Slur blah. blah. + (slur) + */ + class Slur @{@}; + Slur* slur_p = new Slur; + +@end example + +@unnumberedsubsec Modifiers + +The following types modify the meaning of the prefix. +These are preceded by the prefixes: + +@table @samp +@item @code{a} + array +@item @code{array} + user built array. +@item @code{c} + const. Note that the proper order is @code{Type const} + i.s.o. @code{const Type} +@item @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. +@item @code{l} + temporary pointer to object (link) +@item @code{p} + pointer to newed object +@item @code{r} + reference +@end table + +@unnumberedsubsec 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. + +@example + +foo_global_i: a global variable of type int commonly called "foo". + +@end example + +static class members do not need the static_ prefix in the name (the +Class::var notation usually makes it clear that it is static) + +@table @samp +@item @code{loop_i} + Variable loop: an integer +@item @code{u} + Temporary variable: an unsigned integer +@item @code{test_ch} + Variable test: a character +@item @code{first_name_str} + Variable first_name: a String class object +@item @code{last_name_ch_a} + Variable last_name: a @code{char} array +@item @code{foo_i_p} + Variable foo: an @code{Int*} that you must delete +@item @code{bar_i_l} + Variable bar: an @code{Int*} that you must not delete +@end table + +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 + +@example + + static Array foo + +@end example + +@code{foo} can be described as "the static int-pointer user-array", so you get + +@example + + foo_static_l_arr + +@end example + + +@unnumberedsec 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. + +@node Making patches, , , Top + + +@unnumberedsec name + + +PATCHES - track and distribute your code changes + +This page documents how to distribute your changes to GNU lilypond + +We would like to have unified context diffs with full pathnames. A +script automating supplied with Lily. + +Distributing a change normally goes like this: + +@itemize @bullet +@item make your fix/add your code +@item Add changes to CHANGES, and add yourself to Documentation/topdocs/AUTHORS.texi +@item generate a patch, +@item e-mail your patch to one of the mailing lists + gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org +@end itemize + +Please do not send entire files, even if the patch is bigger than the +original. A patch makes it clear what is changed, and it won't +overwrite previous (not yet released) changes. + +@unnumberedsec Generating a patch + +Simple version: run + +@example + make -C lilypond-x.y.z/ distclean + make -C lilypond-x.y.z.NEW/ distclean + diff -urN lilypond-x.y.z/ lilypond-x.y.z.NEW/ +@end example + +Complicated (but automated) version: + +In @file{VERSION}, set MY_PATCH_LEVEL: + +@example + + VERSION: + ... + MY_PATCH_LEVEL=jcn1 + +@end example + +In @file{CHANGES}, enter a summary of changes: + +@example + pl 0.1.73.jcn1 + - added PATCHES.texi +@end example + +Then, from the top of Lily's source tree, type + +@example + make release +@end example + +These handy python scripts assume a directory structure which looks +like: + +@example + + lilypond -> lilypond-x.y.z # symlink to development directory + lilypond-x.y.z/ # current development + patches/ # patches between different releases + releases/ # .tar.gz releases + +@end example + +(Some scripts also assume this lives in @file{$HOME/usr/src}). + + +@unnumberedsec Applying patches + + +If you're following LilyPond development regularly, you probably want to +download just the patch for each subsequent release. +After downloading the patch (into the patches directory, of course), simply +apply it: + +@example + + gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E + +@end example + +and don't forget to make automatically generated files: + +@example + + autoconf footnote(patches don't include automatically generated files, + i.e. file(configure) and files generated by file(configure).) + + configure + +@end example + + +@bye + + diff --git a/Documentation/programmer/lilypond-overview.doc b/Documentation/programmer/lilypond-overview.doc new file mode 100644 index 0000000000..a408a9e8eb --- /dev/null +++ b/Documentation/programmer/lilypond-overview.doc @@ -0,0 +1,743 @@ +%-*-LaTeX-*- + +\documentclass{article} +\usepackage{a4} +\def\postMudelaExample{\setlength{\parindent}{1em}} +\title{LilyPond, a Music Typesetter} +\author{HWN} +\usepackage{musicnotes} +\usepackage{graphics} + + +\begin{document} +\maketitle + +[THIS IS WORK IN PROGRESS. THIS IS NOT FINISHED] + +% -*-LaTeX-*- +\section{Introduction} + +The Internet has become a popular medium for collaborative work on +information. Its success is partly due to its use of simple, text-based +formats. Examples of these formats are HTML and \LaTeX. Anyone can +produce or modify such files using nothing but a text editor, they are +easily processed with run-of-the-mill text tools, and they can be +integrated into other text-based formats. + +Software for processing this information and presenting these formats +in an elegant form is available freely (Netscape, \LaTeX, etc.). +Ubiquitousness of the software and simplicity of the formats have +revolutionised the way people publish text-based information +nowadays. + +In the field of performed music, where the presentation takes the form +of sheet music, such a revolution has not started yet. Let us review +some alternatives that have been available for transmitting sheet +music until now: +\begin{itemize} +\item MIDI\cite{midi}. This format was designed for interchanging performances + of music; one should think of it as a glorified tape recorder + format. It needs dedicated editors, since it is binary. It does + not provide enough information for producing musical scores: some of + the abstract musical content of what is performed is thrown away. + +\item PostScript\cite{Postscript}. This format is a printer control + language. Printed musical scores can be transmitted in PostScript, + but once a score is converted to PostScript, it is virtually + impossible to modify the score in a meaningful way. + +\item Formats for various notation programs. Notation programs either + work with binary formats (e.g., NIFF\cite{niff-web}), need specific + platforms (e.g., Sibelius\cite{sibelius}), are proprietary or + non-portable tools themselves (idem), produce inadequate output + (e.g., MUP\cite{mup}), are based on graphical content (e.g., + MusixTeX\cite{musixtex1}), limit themselves to specific subdomains + (e.g., ABC\cite{abc2mtex}), or require considerable skill and + knowledge to use (e.g., SCORE\cite{score}) + +\item SMDL\cite{smdl-web}. This is a very rich ASCII format, that is + designed for storing many types of music. Unfortunately, there is + no implementation of a program to print music from SMDL available. + Moreover, SMDL is so verbose, that it is not suitable for human + production. + +\item TAB\cite{tablature-web}. Tab (short for tablature) is a popular + format, for interchanging music over e-mail, but it can only be used + for guitar music. +\end{itemize} + +In summary, sheet music is not published and edited on a wide scale +across the internet because no format for music +interchange exists that is: +\begin{itemize} +\item open, i.e., with publically available specifications. +\item based on ASCII, and therefore suitable for human consumption and + production. +\item rich enough for producing publication quality sheet music from + it. +\item based on musical content (unlike, for example, PostScript), and + therefore suitable for making modifications. +\item accompanied by tools for processing it that are freely available + across multiple platforms. +\end{itemize} + + +With the creation of LilyPond, we have tried to create both a +convenient format for storing sheet music, and a portable, +high-quality implementation of a compiler, that compiles the input +into a printable score. You can find a small example of LilyPond +input along with output in Figure~\ref{fig:intro-fig}. +% +\begin{figure}[htbp] + \begin{center} +\begin[verbatim]{mudela} + \score { + \notes + \context GrandStaff < + \transpose c'' { c4 c4 g4 g4 a4 a4 g2 } + { \clef "bass"; c4 c'4 + \context Staff f'4 c'4 e'4 c'4 } + > + \paper { + linewidth = -1.0\cm ; + } + } +\end{mudela} + \caption{A small example of LilyPond input} + \label{fig:intro-fig} + \end{center} +\end{figure} +% + + +The input language encodes musical events (such as notes and rests) on +the basis of their time-ordering. For example, the grammar includes +constructs that specify that notes start simultaneous and that notes +are to be played in sequence. In this encoding some context that is +present in sheet music is lost. + +The compiler reconstructs the notation from the encoded music. Its +operation comprises four different steps (see +Figure~\ref{fig:intro-steps}). + +\begin{description} +\item[Parsing] During parsing, the input is converted in a syntax tree. + +\item[Interpreting] In the \emph{interpreting} step, it is determined + which symbols have to be printed. Objects that correspond to + notation (\emph{Graphical objects}) are created from the syntax tree + in this phase. Generally speaking, for every symbol printed there is + one graphical object. These objects are incomplete: their position + and their final shape is unknown. + + The context that was lost by encoding the input in a language is + reconstructed during this conversion. +\item[Formatting] The next step is determing where symbols are to be + placed, this is called \emph{formatting}. +\item[Outputting] + Finally, all Graphical objects are outputted as PostScript or \TeX\ code. +\end{description} + +\def\staffsym{\vbox to 16pt{ + \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip + \vfil + \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip + \vfil + \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip + \vfil + \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip + \vfil + \hbox{\vrule width 1cm depth .2pt height .2pt}\nointerlineskip +}} + +\def\vspacer{\vbox to 20pt{\vss}} +\begin{figure}[h] +\def\spacedhbox#1{\hbox{\ #1\ }} +\begin{eqnarray*} + {\spacedhbox{Input}\atop \hbox{\texttt{\{c8 c8\}}}} {\spacedhbox{Parsing}\atop\longrightarrow} + {\spacedhbox{Syntax tree}\atop\spacedhbox{\textsf{Sequential(Note,Note)}}} + {\spacedhbox{Interpreting}\atop\longrightarrow}\\ + \vspacer\\ + {\spacedhbox{Graphic objects}\atop\spacedhbox{\texttrebleclef \textquarterhead\texteighthflag\textquarterhead\texteighthflag \staffsym }} + {\spacedhbox{Formatting}\atop\longrightarrow} + {\spacedhbox{Formatted objects}\atop\hbox{ + \mudela{c''8 c''8} + }}\\ +\vspacer\\ + {\spacedhbox{Outputting}\atop\longrightarrow} + {\spacedhbox{PostScript code}\atop\hbox{\texttt{\%!PS-Adobe}\ldots}} +\end{eqnarray*} + \caption{Parsing, Interpreting, Formatting and Outputting} + \label{fig:intro-steps} +\end{figure} + + +The second step, the interpretation phase of the compiler, can be +manipulated as a separate entity: the interpretation process is +composed of many separate modules, and the behaviour of the modules is +parameterised. By recombining these interpretation modules, +and changing parameter settings, the same piece of music can be +printed differently, as is shown in Figure~\ref{fig:intro-interpret}. + +This makes it easy to extend the program. Moreover, this enables the +same music to be printed in different versions, e.g., in a conductors +score and in extracted parts. + + +\begin{figure}[h] + \begin{center} + \begin{mudela} + \score { + \notes + \context GrandStaff < + \transpose c'' { c4 c4 g4 g4 a4 a4 g2 } + { \clef "bass"; c4 c'4 + \context Staff f'4 c'4 e'4 c'4 } + > + \paper { + linewidth = -1.0\cm ; + \translator { + \VoiceContext + \remove "Stem_engraver"; + } + \translator { + \StaffContext + numberOfStaffLines = 3; + } + } + } + \end{mudela} + \caption{The interpretation phase can be manipulated: the same + music as in Figure~\ref{fig:intro-fig} is interpreted + differently: three staff lines and no stems.} + \label{fig:intro-interpret} + \end{center} +\end{figure} + + + +\section{Preliminaries} + +To understand the rest of the article, it is necessary to know +something about music notation and music typography. Since both +communicate music, we will explain some characteristics of instruments +and western music that motivate some notational constructs. + +\subsection{Music} + +Music notation is meant to be read by human performers. They sing or +play instruments that can produce sounds of different pitches. These +sounds are called \emph{notes}. Additionally, the sounds can be +articulated in differents ways, e.g., staccato (short and separated) +or legato (fluently bound together). The loudness of the notes can +also be varied. Changes in loudness are called \emph{dynamics}. + +Silence is also an element of music. The musical terminology for +silence within music is \emph{rest}. + +The basic unit of pitch is the \emph{octave}. The octave corresponds +to a frequency ratio of 1:2. For example the pitch denoted by a' +(frequency: 440 hertz) is one octave lower than a'' (frequency: 880 +hertz). Various instruments have a limited \emph{pitch range}, for +example, a trumpet has a range of about 2.5 octaves. Not all +instruments have ranges in the same register: a tuba also has a range +of 2.5 octaves, but the range of the tuba is much lower. + +Musicology has a confusing mix of relative and absolute measures for +pitches: the term `octave' refers to both a difference between two +pitches (the frequency ratio of 1:2), and to a range of pitches. For +example, the term `[eengestreept] octave' refers to the pitch range +between 261.6 Hz and 523.3 Hz. + + +The octave is divided into smaller pitch steps. In modern western +music, every octave is divided into twelve approximately equidistant +pitch steps, and each step is called a \emph{semitone}. Usually, the +pitches in a musical piece come from a smaller subset of these twelve +possible pitches. This smaller subset along with the musical +functions fo the pitches is called the +\emph{tonality}\footnote{Tonality also refers to the relations between + and functions of certain pitches. Since these do not have any + impact on notation, we ignore this} of the piece. + + +The standard tonality that forms the basis of music notation +(the key of C major) is a set of seven pitches within every octave. +Each of these seven is denoted by a name. In English, these are names +are (in rising pitch) denoted by c, d, e, f, g, a and b. Pitches that +are a semitone higher or lower than one of these seven can be +represented by suffixing the name with `sharp' or `flat' +respectively (this is called an \emph{chromatic alteration}). + +A pitch therefore can be fully specified by a combination of the +octave number, the note name and a chromatic alteration. +Figure~\ref{fig:intro-pitches} shows the relation between names and +frequencies. + + + + +\begin{figure}[h] + \begin{center} + [te doen] + \end{center} + \caption{Pitches in western music. The octave number is denoted + by a superscript.} + \label{fig:intro-pitches} +\end{figure} + + +Many instruments can produce more than one note at the same time, e.g. +pianos and guitars. When more notes are played simultaneously, they +form a so-called \emph{chord}. + +The unit of duration is the \emph{beat}. When playing, the tempo is +determined by setting the number of beats per minute. In western +music, beats are often stressed in a regular pattern: for example +Waltzes have a stress pattern that is strong-weak-weak, i.e. every +note that starts on a `strong' beat is louder and has more pronounced +articulation. This stress pattern is called \emph{meter}. + +\subsection{Music notation} + +Music notation is a system that tries to represent musical ideas +through printed symbols. Music notation has no precise definition, +but most conventions have described in reference manuals on music +notation\cite{read-notation}. + +In music notation, sounds and silences are represented by symbols that +are called note and rest respectively.\footnote{These names serve a + double purpose: the same terms are used to denote the musical + concepts.} The shape of notes and rests indicates their duration +(See figure~\ref{noteshapes}) relative to the whole note. + + +\begin{figure}[h] + \begin{center} +\begin{mudela} + \score { + \notes \transpose c''{ c\longa*1/4 c\breve*1/2 c1 c2 c4 c8 c16 c32 c64 } + \paper { + \translator { + \StaffContext + \remove "Staff_symbol_engraver"; + \remove "Time_signature_engraver"; +% \remove "Bar_engraver"; + \remove "Clef_engraver"; + } +linewidth = -1.; + } +} +\end{mudela} +\begin{mudela} + \score { + \notes \transpose c''\context Staff { r\longa*1/4 r\breve*1/2 r1 r2 r4 r8 r16 r32 r64 } + \paper { + \translator { + \StaffContext + \remove "Staff_symbol_engraver"; + \remove "Time_signature_engraver"; +% \remove "Bar_engraver"; + \remove "Clef_engraver"; + } + linewidth = -1.; + } +} +\end{mudela} + \caption{Note and rest shapes encode the length. At the top notes + are shown, at the bottom rests. From left to right a quadruple + note (\emph{longa}), double (\emph{breve}), whole, half, + quarter, eigth, sixteenth, thirtysecond and sixtyfourth. Each + note has half of the duration of its predecessor.} + \label{fig:noteshapes} +\end{center} +\end{figure} + + +Notes are printed in a grid of horizontal lines called \emph{staff} to +denote their pitch: each line represents the pitch of from the +standard scale (c, d, e, f, g, a, b). The reference point is the +\emph{clef}, eg., the treble clef marks the location of the $g^1$ +pitch. The notes are printed in their time order, from left to right. + + +\begin{figure}[h] + \begin{center} + \begin{mudela} + \score { \notes { + a4 b c d e f g a \clef bass; + a4 b c d e f g a \clef alto; + a4 b c d e f g a \clef treble; + } + \paper { linewidth = 15.\cm; } + } + \end{mudela} + \caption{Pitches ranging from $a, b, c',\ldots a'$, in different + clefs. From left right the bass, alto and treble clef are + featured.} + \label{fig:pitches} + \end{center} +\end{figure} + +The chromatic alterations are indicated by printing a flat sign or a +sharp sign in front of the note head. If these chromatic alterations +occur systematically (if they are part of the tonality of the piece), +then this indicated with a \emph{key signature}. This is a list of +sharp/flat signs which is printed next to the clef. + +Articulation is notated by marking the note shapes wedges, hats and +dots all indicate specific articulations. If the notes are to be +bound fluently (legato), the note shapes are encompassed by a smooth +curve called \emph{slur}, + +\begin{figure}[h] + \begin{center} + \begin{mudela} + c'4-> c'4-. g'4 ( b'4 ) g''4 + \end{mudela} + \caption{Some articulations. From left to right: extra stress + (\emph{marcato}), short (staccato), slurred notes (legato).} + \label{fig:articulation} + \end{center} +\end{figure} + + + +Dynamics are notated in two ways: absolute dynamics are indicated by +letters: \textbf{f} (from Italian ``forte'') stands for loud, +\textbf{p} (from Italian ``piano'') means soft. Gradual changes in +loudness are notated by (de)crescendos. These are hairpin like shapes +below the staff. + +\begin{figure}[h] + \begin{center} + \begin{mudela} + g'4\pp \< g'4 \! g'4 \ff \> g'4 g' \! g'\ppp + \end{mudela} + \caption{Dynamics: start very soft (pp), grow to loud (ff) and + decrease to extremely soft (ppp)} + \label{fig:dynamics} + \end{center} +\end{figure} + + +The meter is indicated by barlines: every start of the stress pattern +is preceded by a vertical line, the \emph{bar line}. The space +between two bar lines is called measure. It is therefore the unit of +the rhythmic pattern. + +The time signature also indicates what kind of rhythmic pattern is +desired. The time signature takes the form of two numbers stacked +vertically. The top number is the number of beats in one measure, the +bottom number is the duration (relative to the whole note) of the note +that takes one beat. Example: 2/4 time signature means ``two beats +per measure, and a quarter note takes one beat'' + +Chords are written by attaching multiple note heads to one stem. When +the composer wants to emphasize the horizontal relationships between +notes, the simultaneous notes can be written as voices (where every +note head has its own stem). A small example is given in +Figure~\ref{fig:simultaneous}. + +\begin{figure}[h] + \begin{center} + \begin{mudela} + \relative c'' {\time 2/4; + \context Staff < \context Voice = VA{ + \stemdown + c4 d + b16 b b b b b b b } + \context Voice = VB { + \stemup e4 f g8 g4 g8 } > + } + \end{mudela} + \caption{Notes sounding together. Chord notation (left, before + the bar line) emphasizes vertical relations, voice notation + emphasizes horizontal relations. Separate voices needn't have + synchronous rhythms (third measure). + } + \label{fig:simultaneous} + \end{center} +\end{figure} + +Separate voices do not have to share one rhythmic pattern---this is +also demonstrated in Figure~\ref{fig:simultaneous}--- they are in a sense%vaag +independent. A different way to express this in notation, is by +printing each voice on a different staff. This is customary when +writing for piano (both left and right hand have a staff of their own) +and for ensemble (every instrument has a staff of its own). + + + +\subsection{Music typography} + +Music typography is the art of placing symbols in esthetically +pleasing configuration. Little is explicitly known about music +typography. There are only a few reference works +available\cite{ross,wanske}. Most of the knowledge of this art has +been transmitted verbally, and was subsequently lost. + +The motivation behind choices in typography is to represent the idea +as clearly as possible. Among others, this results in the following +guidelines: +\begin{itemize} +\item The printed score should use visual hints to accentuate the + musical content +\item The printed score should not contain distracting elements, such + as large empty regions or blotted regions. +\end{itemize} + +An example of the first guideline in action is the horizontal spacing. +The amount of space following a note should reflect the duration of +that note: short notes get a small amount of space, long notes larger +amounts. Such spacing constraints can be subtle, for the +``amount of space'' is only the impression that should be conveyed; there +has to be some correction for optical illusions. See +Figure~\ref{fig:spacing}. + +\begin{figure}[h] + \begin{center} + \begin{mudela} + \relative c'' { \time 3/4; c16 c c c c8 c8 | f4 f, f' } + \end{mudela} + \caption{Spacing conveys information about duration. Sixteenth + notes at the left get less space than quarter notes in the + middle. Spacing is ``visual'', there should be more space + after the first note of the last measure, and less after second. } + \label{fig:spacing} + \end{center} +\end{figure} + +Another example of music typography is clearly visible in collisions. +When chords or separate voices are printed, the notes that start at +the same time should be printed aligned (ie., with the same $x$ +position). If the pitches are close to each other, the note heads +would collide. To prevent this, some notes (or note heads) have to be +shifted horizontally. An example of this is given in +Figure~\ref{fig:collision}. +\begin{figure}[h] + \begin{center} + [todo] + \caption{Collisions} + \label{fig:collision} + \end{center} +\end{figure} + +\bibliographystyle{hw-plain} +\bibliography{engraving,boeken,colorado,computer-notation,other-packages} + +\section{Requirements} + + +\section{Approach} + +\subsection{Input} + +The input format consists of combining a symbolic representation of +music with style sheet that describes how the symbolic presentation +can converted to notation. The symbolic representation is based on a +context free language called \textsf{music}. Music is a recursively +defined construction in the input language. It can be constructed by +combining lists of \textsf{music} sequentially or parallel or from +terminals like notes or lyrics. + +The grammar for \textsf{music} is listed below. It has been edited to +leave out the syntactic and ergonomic details. + +\begin{center} + \begin{tabular}{ll} +Music: & SimpleMusic\\ + & $|$ REPEATED int Music ALTERNATIVE MusicList\\ + & $|$ SIMULTANEOUS MusicList\\ + & $|$ SEQUENTIAL MusicList\\ + & $|$ CONTEXT STRING '=' STRING Music\\ + & $|$ TIMES int int Music \\ + & $|$ TRANSPOSE PITCH Music \\ +SimpleMusic: & $|$ Note\\ + & $|$ Lyric\\ + & $|$ Rest\\ + & $|$ Chord\\ + & $|$ Command\\ +Command: & METERCHANGE\\ + & $|$ CLEFCHANGE\\ + &$|$ PROPERTY STRING '=' STRING\\ +Chord: &PitchList DURATION\\ +Rest: &REST DURATION\\ +Lyric: &STRING DURATION\\ +Note: &PITCH DURATION\\ +\end{tabular} +\end{center} + +The terminals are both purely musical concepts that have a duration, +and take a non-zero amount of musical time, like notes and lyrics, and +commands that behave as if they have no duration.\footnote{The + PROPERTY command is a generic mechanism for controlling the + interpretation, i.e. the musical style sheets. See [forward ref]} + +The nonterminal productions can +\begin{itemize} +\item Some productions combine multiple elements: one can specify that + element are to be played in sequence, simultaneously or repetitively. +\item There are productions for transposing music, and for dilating + durations of music: the TIMES production can be used to encode a + triplet.\footnote{A triplet is a group of three notes marked by a + bracket, that are played 3/2 times faster.} +\item + There are productions that give directions to the interpretation + engine (the CONTEXT production) +\end{itemize} + + +\section{Context in notation} + +Music notation relies heavily on context. Notational symbols do not +have meaning if they are not surrounded by other context elements. In +this section we give some examples how the reader uses this context do +derive meaning of a piece of notation. We will focus on the prime +example of context: the staff. + +A staff is the grid of five horizontal lines, but it contains more components : +\begin{itemize} +\item A staff can have a key signature (printed at the left) +\item A staff can have a time signature (printed at the left) +\item A staff has bar lines +\item A staff has a clef (printed at the left) +\end{itemize} + +It is still possible to print notes without these components, but one +cannot determine the meaning of the notes. +\begin{mudela} +\score{ +\notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 } +\paper { + linewidth = -1.; + \translator { + \StaffContext + \remove "Time_signature_engraver"; +% \remove "Bar_engraver"; + \remove "Staff_symbol_engraver"; + \remove "Clef_engraver"; + \remove "Key_engraver"; + } + } +} +\end{mudela} + +As you can see, you can still make out the general form of the melody +and the rhythm that is to be played, but the notation is difficult to +read and the musical information is not complete. The stress +pattern in the notes can't be deduced from this output. For this, we +need a time signature. Adding barlines helps with finding the strong +and weak beats. +\begin{mudela} +\score { + \notes \relative c' { \time 2/4; g'4 c,4 a'4 f4 e c d2 } + \paper{ + linewidth = -1.; +\translator{ + \StaffContext + \remove "Staff_symbol_engraver"; + \remove "Clef_engraver"; + \remove "Key_engraver";} + } + } +\end{mudela} + +It is impossible to deduce the exact pitch of the notes. One needs a +clef to do so. Staff lines help the eye in determining the vertical +position of a note wrt. to the clef. +\begin{mudela} +\score { + \notes \relative c' {\clef alto; \time 2/4; g'4 c,4 a'4 f4 e c d2 } + \paper { + linewidth = -1.; + } +} +\end{mudela} + +Now you know the pitch of the notes: you look at the start of the line +and see a clef, and with this clef, you can determine the notated pitches. +You have found the em(context) in which the notation is to be +interpreted! + + +\section{Interpretation context} + +Context (clef, time signature etc.) determines the relationship +between musical and its notation in notes. Because LilyPond writes +notation, context works the other way around for LilyPond: with +context a piece of music can be converted to notation. + +A reader remembers this context while reading the notation from left +to right. By analogy, LilyPond constructs this context while +constructing notes from left to right. This is what happens in the +``Interpretation'' phase from~\ref{fig:intro-fig}. In LilyPond, the +state of this context is a set of variables with their values; A staff +context contains variables like + +\begin{itemize} +\item current clef +\item current time signature +\item current key +\end{itemize} + +These variables determine when and how clefs, time signatures, bar +lines and accidentals are printed. + + +Staff is not the only form of context in notation. In polyphonic +music, the stem direction shows which notes form a voice: all notes of +the same voice have stems pointing in the same direction. The value +of this variable determines the appearance of the printed stems. + +In LilyPond ``Notation context'' is abstracted to a data structure +that is used, constructed and modified during the interpretation +phase. It contains context properties, and is responsible for +creating notational elements: the staff context creates symbols for +clefs, time signatures and key signatures. The Voice context creates +stems, note heads. + +For the fragment of polyphonic music below, +\begin{mudela} + \context Staff { c'4 < { \stemup c'4 } \context Voice = VB { \stemdown a4 } > } +\end{mudela} +A staff context is created. Within this staff context (which printed +the clef), a Voice context is created, which prints the first note. +Then, a second Voice context is created, with stem direction set to +``up'', and the direction for the other is set to down. Both Voice +contexts are still part of the same Staff context. + +In the same way, multiple staff scores are created: within the score +context, multiple staff contexts are created. Every staff context +creates the notation associated with a staff. + +\section{Discussion} + + + +\end{document} + +The complexity of music notation was tackled by adopting a modular +design: both the formatting system (which encodes the esthetic rules of +notation), and the interpretation system (which encodes the semantic +rules) are highly modular. + + +The difficulty in creating a format for music notation is rooted in +the fact that music is multi dimensional: each sound has its own +duration, pitch, loudness and articulation. Additionally, multiple +sounds may be played simultaneously. Because of this, there is no +obvious way to ``flatten'' music into a context-free language. + +The difficulty in creating a printing engine is rooted in the fact +that music notation complicated: it is very large graphical +``language'' with many arbitrary esthetic and semantic conventions. +Building a system that formats full fledged musical notation is a +challenge in itself, regardless of whether it is part of a compiler or +an editor. + +The fact that music and its notation are of a different nature, +implies that the conversion between input notation is non-trivial. + +In LilyPond we solved the above problem in the following way: + diff --git a/Documentation/programmer/musicnotes.sty b/Documentation/programmer/musicnotes.sty new file mode 100644 index 0000000000..31d2f83a9c --- /dev/null +++ b/Documentation/programmer/musicnotes.sty @@ -0,0 +1,43 @@ + +\input lilyponddefs + +\def\fetdef#1#2{% + \def#1{\hbox{\char#2}}} + +% huh? from where +\input feta20.sty + +\font\fetasixteenfont=feta16 +\font\fetaelevenfont=feta11 +\def\fetafont{\fetasixteenfont} + +\newdimen\ild +\ild=4pt +\newdimen\stemthick +\stemthick=0.4pt + +\def\eighthstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt\raise + 3.5ex\hbox{\eighthflag}}} +\def\texteighthflag{{\fetafont\raise 0ex\hbox{\fetafont\eighthflag}}} +\def\textdeighthflag{{\fetafont\raise 0ex\hbox{\deighthflag}}} + +\def\texteighthnote{{\hbox{\hbox{\fetafont\quartball}\kern + -0.5\stemthick\eighthstem}}} +\def\quarterstem{{\fetafont\vrule height 3.5ex width \stemthick depth0pt}} +\def\textquarterstem{\quarterstem} +\def\textchord{{\hbox{\fetafont\lower.5ex\hbox to + 0pt{\textquarterhead}\raise.5ex\hbox{\textquarterhead}\kern + -0.5\stemthick\eighthstem}}} +\def\textbassclef{\hbox{\fetafont\bassclef}} +\def\texttrebleclef{\hbox{\fetafont\trebleclef}} +\def\textslur{\embeddedps{9.378744 -3.171539 3.923099 -3.171539 0.000000 0.000000 12.800000 0.000000 3.672177 -3.672177 9.127823 -3.672177 12.800000 0.000000 0.000000 0.000000 draw_slur}} + +\def\textmarcato{{\fetafont\raise 1ex\hbox{\hskip 1ex\sforzatoaccent}}} + + +\def\textquarterhead{\hbox{\fetafont\raise 2.5pt\hbox{\quartball}}} +\def\texteighthstem{\hbox{\lower 5pt\hbox{\eighthstem}}} +\def\texthalfnote{{\hbox{\hbox{\fetafont\halfball}\kern -0.5\stemthick\quarterstem}}} +\def\textquarternote{{\hbox{\hbox{\fetafont\quartball}\kern -0.5\stemthick\quarterstem}}} +\def\textflat{{\fetafont\raise 1ex\hbox{\flat}}} +\def\textsharp{{\fetafont\raise1ex\hbox{\sharp}}} diff --git a/Documentation/programmer/regression-test.tely b/Documentation/programmer/regression-test.tely new file mode 100644 index 0000000000..fe5ee1dbfd --- /dev/null +++ b/Documentation/programmer/regression-test.tely @@ -0,0 +1,312 @@ +\input texinfo @c -*-texinfo-*- vim:tw=72 +@setfilename regression-test.info +@settitle LilyPond Regression test + +@c fool ls-latex +@ignore +@author Han-Wen Nienhuys and Jan Nieuwenhuizen +@title LilyPond Regression test +@end ignore + +@node Top, , , + +@section Introduction + +This document tries give an brief overview of LilyPond features. When +the text correspond with the shown notation, we consider LilyPond +Officially BugFree (tm). This document is intended for finding bugs, +and documenting bugfixes. + +@section Notes and rests + +Rests. Note that the dot of 8th, 16th and 32nd rests rest should be +next to the top of the rest. All rests except the whole rest are +centered on the middle staff line. + +@mudelafile{rest.fly} + +Note head shapes are settable. The stem endings should be adjusted +per note head. If you want different note head styles on one stem, +you must create a special context called Thread. + +@mudelafile{noteheadstyle.ly} + +Noteheads can have dots, and ---although this is bad style in duple +meters--- rests can too. Augmentation dots should never be printed on +a staff line, but rather be shifted vertically. They should go up, but +in case of multiple parts, the down stems have down shifted dots. +(Wanske p. 186) In case of chords, all dots should be in a column. +The dots go along as rests are shifted to avoid collisions. + +@mudelafile{dots.fly} + +Multiple measure rests do not collide with barlines and clefs. They +are not expanded when you set @code{Score.SkipBars}. Although the +multi-measure-rest is a Spanner, minimum distances are set to keep it +colliding from barlines. + +@mudelafile{multi-measure-rest.ly} + +@section Stems + +Stem tremolos (official naming?) or rolls are tremolo signs that look +like beam segments crossing stems. If the stem is in a beam, the +tremolo must be parallel to the beam. If the stem is invisible +(eg. on a whole note), the tremolo must be centered on the note. + +@mudelafile{stem-tremolo.ly} + +Chord tremolos look like beams, but are a kind of repeat symbol. +To avoid confusion, chord tremolo beams do not reach the stems, but +leave a gap. Chord tremolo beams on half notes are not ambiguous, +as half notes cannot appear in a regular beam, and should reach the +stems. + +@mudelafile{chord-tremolo.sly} + +Beams, stems and noteheads often have communication troubles, since +the two systems for y dimensions (1 unit = staffspace, 1 unit = 1 +point) are mixed. + +Stems, beams, ties and slurs should behave similarly, when placed +on the middle staff line. Of course stem-direction is down for high +notes, and up for low notes. + +@mudelafile{stem-direction.sly} + +Similarly, if @code{stem_default_neutral_direction} is set to @code{-1}. + +@mudelafile{stem-direction-down.ly} + +@section Scripts + +The staccato dot (and all scripts with follow-into-staff set), must +not be on staff lines. + +@mudelafile{staccato-pos.sly} + +@section Grace notes + +Grace notes are typeset as an encapsulated piece of music. You can +have beams, notes, chords, stems etc. within a @code{\grace} section. +Slurs that start within a grace section, but aren't ended are attached +to the next normal note. Grace notes have zero duration. If there +are tuplets, the grace notes won't be under the brace. Grace notes +can have accidentals, but they are (currently) spaced at a fixed +distance. Grace notes (of course) come before the accidentals of the +main note. Grace notes can also be positioned after the main note. + +@mudelafile{grace.ly} + + +@section Beams, slurs and other spanners + +Beaming is generated automatically. Beams may cross bar lines. In that +case, line breaks are forbidden. Yet clef and key signatures are +hidden just as with breakable bar lines. + +@mudelafile{beaming.ly} + +Beams should behave reasonably well, even under extreme circumstances. +Stems may be short, but noteheads should never touch the beam. + +@mudelafile{beam-extreme.ly} + +Beams should always reach the middle staff line, the second beam +counting from the note head side, should never be lower than the +second staff line. This does not hold for grace note beams. + +@mudelafile{beam-position.sly} + +Slurs should look nice and symmetric. The curvature may increase +only to avoid noteheads, and as little as possible. + +@mudelafile{slur-symmetry.ly} +@mudelafile{slur-symmetry-1.ly} + +Ties are strictly horizontal. They are placed in between note heads. +The horizontal middle should not overlap with a staffline. + +@mudelafile{tie.ly} + +Beams can be typeset over fixed distance aligned staffs, beam +beautification doesn't really work, but knees do. Beams should be +behave well, wherever the switching point is. + +@mudelafile{beam-cross-staff.ly} + +The same goes for slurs. They behave decently when broken across +linebreak. + +@mudelafile{slur-cross-staff.ly} + +Tuplets are indicated by a bracket with a number. There should be no +bracket if there is one beam that matches the length of the tuplet. +The bracket does not interfere with the stafflines, and the number is +centered in the gap in the bracket. + +@mudelafile{tup.ly} + +@section Repeats + +LilyPond has three modes for repeats: folded, unfolded and +semi-unfolded. Unfolded repeats are fully written out. Semi unfolded +repeats have the body written and all alternatives sequentially. +Folded repeats have the body written and all alternatives +simultaneously. If the number of alternatives is larger than the +repeat count, the excess alternatives are ignored. If the number of +alternatives is smaller, the first alternative is multiplied to get to +the number of repeats. + +Unfolded behavior: + +@mudelafile{repeat-unfold.ly} + +Volta (Semi folded) behavior. Voltas can start on non-barline moments. +If they don't barlines should still be shown. + +@mudelafile{repeat-volta.ly} + +Folded. This doesn't make sense without alternatives, but it works. + +@mudelafile{repeat-fold.ly} + +@section Lyrics + +Lyrics can be set to a melody automatically. Excess lyrics will be +dumped. Lyrics will not be set over rests. You can have melismata +either by setting a property melismaBusy, or by setting +automaticMelismas (which will set melismas during slurs and ties). If +you want a different order than first Music, then Lyrics, you must +precook a chord of staffs/lyrics and label those. Of course +@code{\rhythm} ignores any other rhythms in the piece. Hyphens and +extenders do not assume anything about lyric lengths, so they continue +to work. + +@mudelafile{lyric-combine.ly} + +@section Multiple notes + +Rests should not collide with beams, stems and noteheads. Rests may +be under beams. Rests should be move by integral number of spaces +inside the staff, and by half spaces outside. Notice that the half +and whole rests just outside the staff get ledger lines in different +cases. + +@mudelafile{rest-collision.ly} + +Normal collisions. We have support for polyphony, where the +middle voices are horizontally shifted. + +@mudelafile{collisions.ly} + +The number of stafflines of a staff can be set with the property +numberOfStaffLines. Ledger lines both on note heads and rests are +adjusted. Barlines also are adjusted. + + +@mudelafile{number-staff-lines.fly} + +@section Spacing + +In a limited number of cases, LilyPond corrects for optical spacing +effects. In this example, space for opposite pointed stems is adjusted + +@mudelafile{stem-spacing.sly} + +If there are accidentals in the music, we add space, but the space +between note and accidentals is less than between the notes with the +same value. Clef changes also get extra space, but not as much as +barlines. + + +Even if a line is very tightly spaced, there will still be room +between prefatory matter and the following notes. The space after the +prefatory is very rigid. In contrast, the space before the barline +must stretch like the space within the measure. + +Tight: + +@mudelafile{spacing-tight.ly} + +Natural: + +@mudelafile{spacing-natural.ly} + +Loose: + +@mudelafile{spacing-loose.ly} + +Adding a @code{Bar_engraver} to the LyricsVoice context makes sure that +lyrics don't collide with barlines. + +@mudelafile{lyrics-bar.ly} + +@section Global stuff + +Breaks can be encouraged and discouraged using @code{\break} and +@code{\nobreak}. They are abbrevs for @code{\penalty} commands. + +@mudelafile{break.ly} + + +Markings that are attached to (invisible) barlines are +delicate: the are attached to the rest of the score without the score +knowing it. Consequently, they fall over often. + +@mudelafile{bar-scripts.ly} + +Staff margins are also markings attached to barlines. They should be +left of the staff, and be centered vertically wrt the staff. They may +be on normal staffs, but also on compound staffs, like the PianoStaff + +@mudelafile{staff-margin.ly} + +Breathing signs, also used for phrasing, do normally not influence +global spacing -- only if space gets tight, notes are shifted to make +room for the breathing sign. Breathing signs break beams running +through their voice. In the following example, the notes in the first +two measures all have the same distance from each other: + +@mudelafile{breathing-sign.ly} + +Fonts are available in a default set of sizes: 11, 13, 16, 20, 23 and +26pt staffheight. Sizes of the text fonts and symbol fonts are made +to match the staff dimensions. + +@mudelafile[nofly]{size11.ly} + +@mudelafile[nofly]{size13.ly} + +@mudelafile[nofly]{size16.ly} + +@mudelafile[nofly]{size20.ly} + +@mudelafile[nofly]{size23.ly} + +@mudelafile[nofly]{size26.ly} + + +@section Clefs and Time Signatures + +The transparent clef should not occupy any space and with style +@code{fullSizeChanges}, the changing clef should be typeset in full +size. For octaviated clefs, the ``8'' should appear closely above or +below the clef respectively. The ``8'' is processed in a convoluted +way, so this is fragile as well. + +@mudelafile{clefs.ly} + +@ignore +@c the input file is too long and does not test for specific bugs +By default, time signatures are written with two numbers. With style +``C'', 4/4 and 2/2 are written with their corresponding symbols and +with style ``old'', 2/2, 3/2, 2/4, 3/4, 4/4, 6/4, 9/4, 4/8, 6/8 and +9/8 are typeset with symbols, all other signatures retain the default +layout. The style ``1'', gives single number signatures for all +signatures. +% +\mu delafile{time.fly} +@end ignore + +@bye diff --git a/Documentation/topdocs/index.tely b/Documentation/topdocs/index.tely index 973f35c707..6078fa1349 100644 --- a/Documentation/topdocs/index.tely +++ b/Documentation/topdocs/index.tely @@ -6,27 +6,29 @@ @top - @unnumbered LilyPond -- The @uref{http://www.fsf.org/gnu/gnu-history.html,GNU Project} Music Typesetter + +@html + +@end html + @c something breaks on 3.12 f -@c @center -@quotation -@mudela[fragment] - \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 } -@end mudela -@end quotation -@c @end center -@c include BLURB? LilyPond is a music typesetter. It produces beautiful sheet music using a high level description file as input. LilyPond is part of the GNU Project. -@c include screenshot +@c @center +@quotation +@mudela[fragment] + \relative c'' { \key es; r8 [c16 b] [c8 g] [as c16 b] [c8 d] | g,4 } +@end mudela +@end quotation +@c @end center @unnumberedsec Sheet music diff --git a/TODO b/TODO index bd1b4f9110..a3956ed09b 100644 --- a/TODO +++ b/TODO @@ -9,12 +9,20 @@ Most of the items are marked in the code as well Grep -i for TODO, FIXME and ugh/ugr/urg. .* TODO +. * make this file understandable for 3rd parties. . * use Rhythmic_head::position_i () for all Staff_referenced . * .po -> .pot. . * why need to run -C mf twice? . * fix interstaff stuff . * junk BLURB files. . * setting indent to 0 with \shape fails +. * here's no difference at all in output. When either is jacked up to 7.0, +everything works and matches up; when either is set just a bit above the +default 5.0 (5.4 is what I was hoping to use), stems miss note heads. So +it's some sort of a numerical (truncation/roundoff) problem. +John +. * metre -> meter +. * Fixed size staff heights; . * ly2dvi : don't repeat opus if same. . * breaks before mmrests are favored. . * hara kiri _8 clef. @@ -83,6 +91,7 @@ melismatic. What's old about absolute to relative conversion? Could maybe use for abc2ly, midi2ly? + .* Cleanups needed . * \$ and $ identifier syntax in examples. . * Junk ghost positioning objects eg, Script leans on Staffside diff --git a/VERSION b/VERSION index bac0e1065b..406f84b12f 100644 --- a/VERSION +++ b/VERSION @@ -1,8 +1,8 @@ PACKAGE_NAME=LilyPond MAJOR_VERSION=1 MINOR_VERSION=2 -PATCH_LEVEL=15 -MY_PATCH_LEVEL=jcn4 +PATCH_LEVEL=16 +MY_PATCH_LEVEL= # use the above to send patches: MY_PATCH_LEVEL is always empty for a # released version. diff --git a/input/test/beam-cross-staff.ly b/input/test/beam-cross-staff.ly new file mode 100644 index 0000000000..376b25c3c9 --- /dev/null +++ b/input/test/beam-cross-staff.ly @@ -0,0 +1,33 @@ +\score{ + \context PianoStaff < + \context Staff=one \notes\relative c'{ + \stemup [c8 c \translator Staff=two \stemup c c] + [c c c c] + \translator Staff=one + \stemdown [c8 c \translator Staff=two \stemup c c] + r2 + \stemdown [c8 c \translator Staff=one \stemdown c c] + r2 + \translator Staff=two + \stemup [c8 c \translator Staff=one \stemdown c c] + r2 + } + \context Staff=two \notes\relative c'{ + \clef bass; + s1 + s1 + s1 + s1 + } + > + \paper{ + \translator{ + \PianoStaffContext + minVerticalAlign = 3.0*\staffheight; + maxVerticalAlign = 3.0*\staffheight; + } +% linewidth=-1.; + } +} + +\version "1.2.0"; diff --git a/input/test/beam-interstaff.ly b/input/test/beam-interstaff.ly deleted file mode 100644 index 376b25c3c9..0000000000 --- a/input/test/beam-interstaff.ly +++ /dev/null @@ -1,33 +0,0 @@ -\score{ - \context PianoStaff < - \context Staff=one \notes\relative c'{ - \stemup [c8 c \translator Staff=two \stemup c c] - [c c c c] - \translator Staff=one - \stemdown [c8 c \translator Staff=two \stemup c c] - r2 - \stemdown [c8 c \translator Staff=one \stemdown c c] - r2 - \translator Staff=two - \stemup [c8 c \translator Staff=one \stemdown c c] - r2 - } - \context Staff=two \notes\relative c'{ - \clef bass; - s1 - s1 - s1 - s1 - } - > - \paper{ - \translator{ - \PianoStaffContext - minVerticalAlign = 3.0*\staffheight; - maxVerticalAlign = 3.0*\staffheight; - } -% linewidth=-1.; - } -} - -\version "1.2.0"; diff --git a/input/test/embedded-scm.ly b/input/test/embedded-scm.ly deleted file mode 100644 index d530c85965..0000000000 --- a/input/test/embedded-scm.ly +++ /dev/null @@ -1,4 +0,0 @@ -#(begin (newline)(display "hello world")(newline))\score{ - \notes\relative c'{ c } -} - diff --git a/input/test/no-stem-extend.fly b/input/test/no-stem-extend.fly new file mode 100644 index 0000000000..35ef31eac4 --- /dev/null +++ b/input/test/no-stem-extend.fly @@ -0,0 +1,13 @@ +% test noStemExtend +\context Staff < + \context Voice = "a" { + f2 f8 g a b + \property Voice.noStemExtend = 1 + f2 f8 g a b + } + \context Voice = "b" { + c''2 c8 b a g + \property Voice.noStemExtend = 1 + c2 c8 b a g + } +> diff --git a/input/test/slur-cross-staff.ly b/input/test/slur-cross-staff.ly new file mode 100644 index 0000000000..e53a579f89 --- /dev/null +++ b/input/test/slur-cross-staff.ly @@ -0,0 +1,39 @@ +\score{ + \context PianoStaff < + \context Staff=one \notes\relative c'{ + \stemup c4( c \translator Staff=two c )c | + \translator Staff=one + \stemup c4( c \translator Staff=two c )c | + \stemup c4( c \translator Staff=one c )c | + \translator Staff=two + \stemup c4( c \translator Staff=one c )c | + \translator Staff=two + \stemup c4( \translator Staff=one c c )c | + r2 + \translator Staff=two + \stemup c4( \translator Staff=one c + \break + c )c + r2 +% \stemdown c4( \translator Staff=two c c \translator Staff=one )c + \stemdown d4( \translator Staff=two c c \translator Staff=one )d + \translator Staff=two + \stemup c4( \translator Staff=one c c \translator Staff=two )c + r1 + } + \context Staff=two \notes\relative c'{ + \clef bass; + s1 s1 s1 s1 s1 s1 s1 s1 s1 s1 + } + > + \paper{ + \translator{ + \PianoStaffContext + minVerticalAlign = 3.0*\staffheight; + maxVerticalAlign = 3.0*\staffheight; + } + %linewidth=100.\mm; + } +} + +\version "1.2.0"; diff --git a/input/test/slur-interstaff.ly b/input/test/slur-interstaff.ly deleted file mode 100644 index e53a579f89..0000000000 --- a/input/test/slur-interstaff.ly +++ /dev/null @@ -1,39 +0,0 @@ -\score{ - \context PianoStaff < - \context Staff=one \notes\relative c'{ - \stemup c4( c \translator Staff=two c )c | - \translator Staff=one - \stemup c4( c \translator Staff=two c )c | - \stemup c4( c \translator Staff=one c )c | - \translator Staff=two - \stemup c4( c \translator Staff=one c )c | - \translator Staff=two - \stemup c4( \translator Staff=one c c )c | - r2 - \translator Staff=two - \stemup c4( \translator Staff=one c - \break - c )c - r2 -% \stemdown c4( \translator Staff=two c c \translator Staff=one )c - \stemdown d4( \translator Staff=two c c \translator Staff=one )d - \translator Staff=two - \stemup c4( \translator Staff=one c c \translator Staff=two )c - r1 - } - \context Staff=two \notes\relative c'{ - \clef bass; - s1 s1 s1 s1 s1 s1 s1 s1 s1 s1 - } - > - \paper{ - \translator{ - \PianoStaffContext - minVerticalAlign = 3.0*\staffheight; - maxVerticalAlign = 3.0*\staffheight; - } - %linewidth=100.\mm; - } -} - -\version "1.2.0"; diff --git a/input/test/uniform-breaking.ly b/input/test/uniform-breaking.ly new file mode 100644 index 0000000000..b07a7b21a6 --- /dev/null +++ b/input/test/uniform-breaking.ly @@ -0,0 +1,112 @@ +%{ +Hmm, ik vraag me af of dit al helemaal koel is. + + return abs (this_one.force_f_) + abs (prev.force_f_ - this_one.force_f_) + + break_penalties; + +Neem als voorbeeld iets dat lijkt op allemande: keuze tussen 2 of drie +maten per regel. + +* 2 lange maten -> lelie kiest 2 /regel :beetje los +* 3 korte -> lelie kiest 3 /regel :beetje krap +* 2 korte, 1 lange -> 3/regel :krap +* 1 korte, 2 lange -> 3/regel :erg krap +* 3 lange -> 3/regel :urg krap + +als je naar beloningen kijkt, kan ik me goed voorstellen dat sprong +van 'al wat krapper' naar los te groot wordt, en ze dus steeds krapper +wordt, tot urg krap aan toe, want kracht lineair? Dat lijkt ook geval +in allemande. + +Zie hoe eerst 10 en 9 mooi op 2maat/regel staan terwijl later tot 14 +toe 3/regel. + +Heb niet zomaar beter idee, nog. +%} + +\score{ + \notes\relative c'{ + % 10 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c c8 ces c ces + + % 9 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c c8 c ces c + + % 1 + c4 c c c + c4 c c c + c4 c c c + + % 2 + c4 c c c + c4 c c c + c4 c c8 c c c + + % 3 + c4 c c c + c4 c c c + c8 c c c c8 c c c + + % 4 + c4 c c c + c4 c c8 c c c + c8 c c c c8 c c c + + % 5 + c4 c c c + c8 c c c c8 c c c + c8 c c c c8 c c c + + % 6 + c4 c c8 c c c + % c4 c c c8 c + c8 c c c c8 c c c + c8 c c c c8 c c c + + % 7 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c c8 c c c + + % 8 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c c8 c c ces + + % 9 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c c8 c ces c + + % 10 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c c8 ces c ces + + % 11 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c c ces8 c ces c + + % 12 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c c ces c8 ces c ces + + % 13 + c8 c c c c8 c c c + c8 c c c c8 c c c + c8 c ces c ces8 c ces c + + } + \paper { + indent=0.0\mm; + linewidth=90.0\mm; + } +} + + diff --git a/input/twinkle.ly b/input/twinkle.ly index bc8d67cbe3..847368ebeb 100644 --- a/input/twinkle.ly +++ b/input/twinkle.ly @@ -48,9 +48,6 @@ accompany = \notes \relative c { d b | c a | f g | c,2 } -global = \notes { - \time 2/4; -} tekst = \lyrics{ Al -- tijd is Kort -- jak -- je ziek, " " @@ -120,14 +117,16 @@ textiii = \lyrics{ \context Staff=i s1 \context Lyrics=top s1 \context GrandStaff < - \context Staff=ii \repeat semi 2 < \global\melody > - \context Staff=iii \repeat semi 2 < \global\accompany > + \context Staff=ii \repeat volta 2 < + \time 2/4; + \melody > + \context Staff=iii \repeat volta 2 < + \accompany > > \context Lyrics=bottom s1 % ugh, \repeat in \addlyrics dumps core \addlyrics - % \context Staff = i \repeat semi 2 <\global\melody> - \context Staff = i <\global\melody> + \context Staff = i < \melody> < %\repeat fold 2 {} %\alternative { diff --git a/lily/breathing-sign-engraver.cc b/lily/breathing-sign-engraver.cc index e9f243532b..d574fb57d4 100644 --- a/lily/breathing-sign-engraver.cc +++ b/lily/breathing-sign-engraver.cc @@ -21,7 +21,6 @@ TODO: #include "note-head.hh" #include "local-key-item.hh" -#include Breathing_sign_engraver::Breathing_sign_engraver() { diff --git a/lily/breathing-sign.cc b/lily/breathing-sign.cc index 4c36f261aa..0fff51106f 100644 --- a/lily/breathing-sign.cc +++ b/lily/breathing-sign.cc @@ -18,7 +18,6 @@ TODO: --> see breathing-sign-engraver.cc #include "dimensions.hh" #include "direction.hh" -#include Breathing_sign::Breathing_sign () { diff --git a/lily/include/lily-guile.hh b/lily/include/lily-guile.hh index 55719cb91b..90773ac8d1 100644 --- a/lily/include/lily-guile.hh +++ b/lily/include/lily-guile.hh @@ -24,7 +24,6 @@ SCM ly_set_scm (String name , SCM val); SCM ly_append (SCM a, SCM b); SCM ly_eval (SCM a); SCM ly_func_o (char const* name); -SCM ly_parse_scm (char const* s, int* n); SCM ly_quote_scm (SCM s); void ly_display_scm (SCM s); String ly_scm2string (SCM s); diff --git a/lily/include/ly-symbols.hh b/lily/include/ly-symbols.hh index f0f3dd098d..0e3f1cf746 100644 --- a/lily/include/ly-symbols.hh +++ b/lily/include/ly-symbols.hh @@ -60,6 +60,7 @@ DECLARE_LY_SYMBOL(notewidth); DECLARE_LY_SYMBOL(non_default); DECLARE_LY_SYMBOL(non_rhythmic); DECLARE_LY_SYMBOL(no_staff_support); +DECLARE_LY_SYMBOL(no_stem_extend); DECLARE_LY_SYMBOL(octave_dir); DECLARE_LY_SYMBOL(origin); DECLARE_LY_SYMBOL(output); diff --git a/lily/include/midi-stream.hh b/lily/include/midi-stream.hh index f367d62a2a..06c4f84ffc 100644 --- a/lily/include/midi-stream.hh +++ b/lily/include/midi-stream.hh @@ -7,7 +7,6 @@ #ifndef MIDI_STREAM_HH #define MIDI_STREAM_HH -#include #include "string.hh" /// Midi outputfile diff --git a/lily/include/music-iterator.hh b/lily/include/music-iterator.hh index d5ca0e0560..f7d9c061e3 100644 --- a/lily/include/music-iterator.hh +++ b/lily/include/music-iterator.hh @@ -28,8 +28,6 @@ class Music_iterator { Interpretation_context_handle handle_; protected: - bool playback_b_; // Should use SCMs - Music const * music_l_; /// ugh. JUNKME @@ -75,9 +73,9 @@ public: void set_translator (Translator_group*); /** Get an iterator matching the type of MUS, and use TRANS to find - an accompanying translation unit. Repeated music can be fully - unfolded by setting PLAYING */ - static Music_iterator* static_get_iterator_p (Music const* mus, bool playing); + an accompanying translation unit + */ + static Music_iterator* static_get_iterator_p (Music const* mus); void init_translator (Music const *, Translator_group *); Music_iterator(); diff --git a/lily/include/paper-stream.hh b/lily/include/paper-stream.hh index e5429511f6..39b49013af 100644 --- a/lily/include/paper-stream.hh +++ b/lily/include/paper-stream.hh @@ -1,7 +1,6 @@ #ifndef PAPER_STREAM_HH #define PAPER_STREAM_HH -#include #include "string.hh" /** Paper output diff --git a/lily/lexer.ll b/lily/lexer.ll index a59d10de16..42e4996c58 100644 --- a/lily/lexer.ll +++ b/lily/lexer.ll @@ -4,8 +4,7 @@ source file of the LilyPond music typesetter - (c) 1996--1999 Han-Wen Nienhuys - Jan Nieuwenhuizen + (c) 1996,1997 Han-Wen Nienhuys */ @@ -30,7 +29,6 @@ #include "my-lily-lexer.hh" #include "array.hh" #include "interval.hh" -#include "lily-guile.hh" #include "parser.hh" #include "debug.hh" #include "main.hh" @@ -233,33 +231,6 @@ HYPHEN -- cerr << _ ("white expected") << endl; exit (1); } -# { //embedded scm - //char const* s = YYText () + 1; - char* s = (char*)YYText () + 1; - int n = 0; - if (!main_input_b_ && safe_global_b) { - error (_ ("Can't evaluate Scheme in safe mode")); - return SCM_EOL; - } - /* - urg: replace 0 char with original value - */ - *s = (char)yyinput (); - yylval.scm = ly_parse_scm (s, &n); - - if (!n) - unput (*s); - else - n--; - /* - urg, this - yyin->seekg (n, ios::cur); - doesn't work, is there no other way? - */ - for (int i=0; i < n; i++) - yyinput (); - return SCM_T; -} { {ALPHAWORD} { return scan_bare_word (YYText ()); diff --git a/lily/lily-guile.cc b/lily/lily-guile.cc index ded411da83..d46d4255ea 100644 --- a/lily/lily-guile.cc +++ b/lily/lily-guile.cc @@ -33,41 +33,6 @@ ly_ch_C_eval_scm (char const*c) return gh_eval_str ((char*)c); } - -/* - Pass string to scm parser, evaluate one expression. - Return result value and #chars read. - - Thanks to Gary Houston - - Need guile-1.3.4 (>1.3 anyway) for ftell on str ports -- jcn -*/ -SCM -ly_parse_scm (char const* s, int* n) -{ - SCM str = gh_str02scm ((char*)s); - SCM port = scm_mkstrport (SCM_INUM0, str, SCM_OPN | SCM_RDNG, - "scm_eval_0str"); - SCM from = scm_ftell (port); - - SCM form; - SCM answer = SCM_UNSPECIFIED; - - /* Read expression from port */ - if (!SCM_EOF_OBJECT_P (form = scm_read (port))) - answer = scm_eval_x (form); - - SCM to = scm_ftell (port); - *n = gh_scm2int (to) - gh_scm2int (from); - - /* Don't close the port here; if we re-enter this function via a - continuation, then the next time we enter it, we'll get an error. - It's a string port anyway, so there's no advantage to closing it - early. */ - - return answer; -} - /* scm_m_quote doesn't use any env, but needs one for a good signature in GUILE. */ @@ -164,7 +129,7 @@ ly_scm2string (SCM s) char * p = gh_scm2newstr (s , &len); String r (p); - // delete p; + free (p); return r; } diff --git a/lily/music-iterator.cc b/lily/music-iterator.cc index e5774c9f32..9de2bb6af7 100644 --- a/lily/music-iterator.cc +++ b/lily/music-iterator.cc @@ -114,7 +114,7 @@ Music_iterator::ok() const } Music_iterator* -Music_iterator::static_get_iterator_p (Music const *m, bool playing) +Music_iterator::static_get_iterator_p (Music const *m) { Music_iterator * p =0; @@ -142,15 +142,14 @@ Music_iterator::static_get_iterator_p (Music const *m, bool playing) p = new Music_wrapper_iterator; else if (Repeated_music const * n = dynamic_cast (m)) { - if (n->fold_b_ && !playing) + if (n->fold_b_) p = new Folded_repeat_iterator; else p = new Unfolded_repeat_iterator; } else assert (0); - - p->playback_b_ = playing; + p->music_l_ = m; return p; @@ -177,7 +176,7 @@ Music_iterator::init_translator (Music const *m, Translator_group *report_l) Music_iterator* Music_iterator::get_iterator_p (Music const*m) const { - Music_iterator*p = static_get_iterator_p (m, playback_b_); + Music_iterator*p = static_get_iterator_p (m); p->init_translator (m, report_to_l()); p->construct_children(); @@ -186,7 +185,6 @@ Music_iterator::get_iterator_p (Music const*m) const Music_iterator::Music_iterator() { - playback_b_ = false; first_b_ = true; } diff --git a/lily/my-lily-lexer.cc b/lily/my-lily-lexer.cc index d58d5a49b7..49d84d6335 100644 --- a/lily/my-lily-lexer.cc +++ b/lily/my-lily-lexer.cc @@ -11,7 +11,6 @@ #include "notename-table.hh" #include "interval.hh" #include "identifier.hh" -#include "lily-guile.hh" #include "parser.hh" #include "keyword.hh" #include "my-lily-lexer.hh" @@ -65,6 +64,8 @@ static Keyword_ent the_key_tab[]={ {"repeat", REPEAT}, {"repetitions", REPETITIONS}, {"addlyrics", ADDLYRICS}, + {"scm", SCM_T}, + {"scmfile", SCMFILE}, {"score", SCORE}, {"script", SCRIPT}, {"shape", SHAPE}, diff --git a/lily/my-lily-parser.cc b/lily/my-lily-parser.cc index 11ae2eeda4..aaae6a6d94 100644 --- a/lily/my-lily-parser.cc +++ b/lily/my-lily-parser.cc @@ -14,7 +14,6 @@ #include "music-list.hh" #include "musical-request.hh" #include "command-request.hh" -#include "lily-guile.hh" #include "parser.hh" #include "scope.hh" #include "file-results.hh" diff --git a/lily/paper-score.cc b/lily/paper-score.cc index ef983e8053..d8cba19d43 100644 --- a/lily/paper-score.cc +++ b/lily/paper-score.cc @@ -50,6 +50,9 @@ Paper_score::typeset_element (Score_element * elem_p) SCM_CDR(element_smob_list_) = gh_cons (elem_p->self_scm_, SCM_CDR (element_smob_list_)); + elem_p->set_elt_property (ly_symbol ("full-name"), + gh_str02scm((char*)elem_p->name())); + scm_unprotect_object (elem_p->self_scm_); } diff --git a/lily/parser.yy b/lily/parser.yy index c57599860d..4d84041f38 100644 --- a/lily/parser.yy +++ b/lily/parser.yy @@ -5,7 +5,7 @@ source file of the GNU LilyPond music typesetter - (c) 1997--1999 Han-Wen Nienhuys + (c) 1997 Han-Wen Nienhuys Jan Nieuwenhuizen */ @@ -99,7 +99,6 @@ print_mudela_versions (ostream &os) Real real; Request * request; Scalar *scalar; - SCM scm; String *string; Tempo_req *tempo; @@ -171,6 +170,7 @@ yylex (YYSTYPE *s, void * v_l) %token REPETITIONS %token ADDLYRICS %token SCM_T +%token SCMFILE %token SCORE %token SCRIPT %token SHAPE @@ -208,7 +208,6 @@ yylex (YYSTYPE *s, void * v_l) %token REAL %token DURATION RESTNAME %token STRING -%token SCM_T %token UNSIGNED @@ -240,7 +239,6 @@ yylex (YYSTYPE *s, void * v_l) %type duration_length %type scalar -%type embedded_scm %type Music Sequential_music Simultaneous_music Music_sequence %type relative_music re_rhythmed_music %type property_def translator_change @@ -302,14 +300,21 @@ toplevel_expression: Midi_def_identifier ($1, MIDI_IDENTIFIER); THIS->lexer_p_->set_identifier ("$defaultmidi", id) } - | embedded_scm { - // junk value - } + | embedded_scm { + } ; embedded_scm: - SCM_T - ; + SCMFILE STRING semicolon { + read_lily_scm_file (*$2); + delete $2; + } + | SCM_T STRING semicolon { + if (THIS->lexer_p_->main_input_b_ && safe_global_b) + error (_("Can't evaluate Scheme in safe mode")); + gh_eval_str ($2->ch_l ()); + delete $2; + }; chordmodifiers_block: diff --git a/lily/protected-scm.cc b/lily/protected-scm.cc index cf06c84a5d..1d8fd16b2a 100644 --- a/lily/protected-scm.cc +++ b/lily/protected-scm.cc @@ -10,14 +10,6 @@ #include "lily-guile.hh" #include "main.hh" -#ifdef LYPROT -#define PROTECT ly_protect_scm -#define UNPROTECT ly_unprotect_scm -#else -#define PROTECT scm_protect_object -#define UNPROTECT scm_unprotect_object -#endif - Protected_scm::Protected_scm () { object_ = 0; @@ -25,12 +17,12 @@ Protected_scm::Protected_scm () Protected_scm::Protected_scm (SCM s) { - object_ = s ? PROTECT (s): 0; + object_ = s ? scm_protect_object (s): 0; } Protected_scm::Protected_scm (Protected_scm const &s) { - object_ = s.object_ ? PROTECT (s.object_) : 0; + object_ = s.object_ ? scm_protect_object (s.object_) : 0; } Protected_scm & @@ -39,9 +31,9 @@ Protected_scm::operator =(SCM s) if (object_ == s) return *this; if (object_) - UNPROTECT(object_); + scm_unprotect_object(object_); - object_ = s ? PROTECT (s): 0; + object_ = s ? scm_protect_object (s): 0; return *this; } @@ -56,8 +48,7 @@ Protected_scm::~Protected_scm () { if (object_) { - UNPROTECT (object_); - object_ =0L; // be nice to conservative GC + scm_unprotect_object (object_); } } diff --git a/lily/score-element.cc b/lily/score-element.cc index 8ab1a73889..666b4c58ab 100644 --- a/lily/score-element.cc +++ b/lily/score-element.cc @@ -70,7 +70,7 @@ Score_element::Score_element (Score_element const&s) Score_element::~Score_element() { - delete output_p_; + assert (!output_p_); assert (status_i_ >=0); status_i_ = -1; } @@ -446,7 +446,11 @@ Score_element::smobify_self () { if (self_scm_ != SCM_EOL) return self_scm_; - + + /* + This is local. We don't assign to self_scm_ directly, to assure + that S isn't GC-ed from under us. + */ SCM s; SCM_NEWCELL(s); @@ -467,7 +471,14 @@ Score_element::mark_smob (SCM ses) void * mp = (void*) SCM_CDR(ses); Score_element * s = (Score_element*) mp; - assert (s->self_scm_ == ses); + if (s->self_scm_ != ses) + { + programming_error ("Score_element::mark_smob(): self_scm_ != ses; this will probably crash"); + cout << "ses == " << ses << endl; + cout << "name == " << s->name() << endl; + gh_display (s->element_property_alist_); + gh_newline (); + } return s->element_property_alist_; } diff --git a/lily/score.cc b/lily/score.cc index 5f9a2b65c5..19e7d8ba26 100644 --- a/lily/score.cc +++ b/lily/score.cc @@ -60,8 +60,7 @@ Score::run_translator (Music_output_def *odef_l) trans_p->last_mom_ = music_p_->length_mom (); - bool playing = odef_l->scope_p_->elem_b ("unfold_all"); - Music_iterator * iter = Music_iterator::static_get_iterator_p (music_p_, playing); + Music_iterator * iter = Music_iterator::static_get_iterator_p (music_p_); iter->init_translator(music_p_, trans_p); iter->construct_children(); diff --git a/lily/simultaneous-music-iterator.cc b/lily/simultaneous-music-iterator.cc index 7f1ff97560..1faaa67c13 100644 --- a/lily/simultaneous-music-iterator.cc +++ b/lily/simultaneous-music-iterator.cc @@ -31,7 +31,7 @@ Simultaneous_music_iterator::construct_children() Cons *i = (sim->music_p_list_p_) ? sim->music_p_list_p_->head_ : 0; for (; i; i = i->next_, j++) { - Music_iterator * mi = static_get_iterator_p (i->car_, playback_b_); + Music_iterator * mi = static_get_iterator_p (i->car_); /* if separate_contexts_b_ is set, create a new context with the number number as name */ diff --git a/lily/slur.cc b/lily/slur.cc index c8582e8abb..04b22471c0 100644 --- a/lily/slur.cc +++ b/lily/slur.cc @@ -243,11 +243,11 @@ Slur::do_post_processing () } while (flip (&d) != LEFT); - bool cross_count = cross_staff_count (); + int cross_count = cross_staff_count (); bool interstaff_b = (0 < cross_count) && (cross_count < encompass_arr_.size ()); Drul_array info_drul; - Interval interstaff_interval; + Drul_array interstaff_interval; do { @@ -257,7 +257,7 @@ Slur::do_post_processing () } while (flip (&d) != LEFT); - Real interstaff_f = interstaff_interval.length (); + Real interstaff_f = interstaff_interval[RIGHT] - interstaff_interval[LEFT]; if (fix_broken_b) { diff --git a/lily/stem-engraver.cc b/lily/stem-engraver.cc index 1679e52441..48cd944514 100644 --- a/lily/stem-engraver.cc +++ b/lily/stem-engraver.cc @@ -130,6 +130,12 @@ Stem_engraver::do_pre_move_processing() stem_p_->set_elt_property (style_scm_sym, ly_ch_C_to_scm (prop.ch_C())); } + prop = get_property ("noStemExtend", 0); + if (prop.to_bool ()) + { + stem_p_->set_elt_property (no_stem_extend_scm_sym, gh_int2scm (1)); + } + typeset_element(stem_p_); stem_p_ = 0; } diff --git a/lily/stem-info.cc b/lily/stem-info.cc index 4a9e06e05e..f555ab0a6b 100644 --- a/lily/stem-info.cc +++ b/lily/stem-info.cc @@ -35,7 +35,6 @@ Stem_info::Stem_info (Stem*s, int mult) SCM bd = stem_l_->remove_elt_property (beam_dir_scm_sym); beam_dir_ = gh_scm2int (SCM_CDR(bd)); - interstaff_f_ = 0; Paper_def* paper_l = stem_l_->paper_l (); Real internote_f = stem_l_->staff_line_leading_f ()/2; @@ -53,6 +52,8 @@ Stem_info::Stem_info (Stem*s, int mult) idealy_f_ *= beam_dir_; bool grace_b = stem_l_->get_elt_property (grace_scm_sym) != SCM_BOOL_F; + bool no_extend_b = stem_l_->get_elt_property (no_stem_extend_scm_sym) + != SCM_BOOL_F; int stem_max = (int)rint(paper_l->get_var ("stem_max")); String type_str = grace_b ? "grace_" : ""; @@ -85,7 +86,7 @@ Stem_info::Stem_info (Stem*s, int mult) than middle staffline, just as normal stems. */ - if (!grace_b) + if (!grace_b && !no_extend_b) { //highest beam of (UP) beam must never be lower than middle staffline miny_f_ = miny_f_ >? 0; @@ -116,9 +117,9 @@ Stem_info::Stem_info (Stem*s, int mult) // interstaff beam Beam* beam_l = stem_l_->beam_l_; - Real is = calc_interstaff_dist (stem_l_, beam_l); - idealy_f_ += is* beam_dir_; - miny_f_ += is * beam_dir_; - maxy_f_ += is * beam_dir_; + interstaff_f_ = calc_interstaff_dist (stem_l_, beam_l) / internote_f; + idealy_f_ += interstaff_f_* beam_dir_; + miny_f_ += interstaff_f_ * beam_dir_; + maxy_f_ += interstaff_f_ * beam_dir_; } diff --git a/lily/stem.cc b/lily/stem.cc index 919969187c..7c7797a385 100644 --- a/lily/stem.cc +++ b/lily/stem.cc @@ -201,7 +201,8 @@ Stem::set_default_stemlen () set_stemend ((dir_ > 0) ? head_positions()[BIGGER] + length_f: head_positions()[SMALLER] - length_f); - if (!grace_b && (dir_ * stem_end_f () < 0)) + bool no_extend_b = get_elt_property (no_stem_extend_scm_sym) != SCM_BOOL_F; + if (!grace_b && !no_extend_b && (dir_ * stem_end_f () < 0)) set_stemend (0); } diff --git a/lily/unfolded-repeat-iterator.cc b/lily/unfolded-repeat-iterator.cc index 901d69f80b..cbc5e008a6 100644 --- a/lily/unfolded-repeat-iterator.cc +++ b/lily/unfolded-repeat-iterator.cc @@ -49,7 +49,7 @@ Unfolded_repeat_iterator::next_element () { done_mom_ += mus->repeat_body_p_->length_mom (); - if (full_unfold_b_) + if (!mus->volta_fold_b_) done_count_ ++; if (alternative_cons_l_) @@ -57,7 +57,7 @@ Unfolded_repeat_iterator::next_element () current_iter_p_ = get_iterator_p (alternative_cons_l_->car_); do_main_b_ = false; } - else if (done_count_ < mus->repeats_i_ && full_unfold_b_) + else if (done_count_ < mus->repeats_i_ && !mus->volta_fold_b_) { current_iter_p_ = get_iterator_p (mus->repeat_body_p_); do_main_b_ = true; @@ -73,20 +73,20 @@ Unfolded_repeat_iterator::next_element () { done_mom_ += alternative_cons_l_->car_->length_mom (); - if (!full_unfold_b_ || + if (mus->volta_fold_b_ || mus->repeats_i_ - done_count_ < alternative_count_i_) alternative_cons_l_ = alternative_cons_l_->next_; /* we've done the main body as well, but didn't go over the other increment. */ - if (full_unfold_b_) + if (mus->volta_fold_b_) done_count_ ++; } if (done_count_ < mus->repeats_i_ && alternative_cons_l_) { - if (!full_unfold_b_) + if (mus->volta_fold_b_) current_iter_p_ = get_iterator_p (alternative_cons_l_->car_); else { @@ -114,8 +114,6 @@ void Unfolded_repeat_iterator::construct_children () { Repeated_music const* mus =dynamic_cast (music_l_); - full_unfold_b_ = playback_b_ || (!mus->volta_fold_b_); - alternative_cons_l_ = (mus->alternatives_p_) ? mus->alternatives_p_->music_p_list_p_->head_ : 0; diff --git a/ly/accordion-defs.ly b/ly/accordion-defs.ly index 1c90a9c16f..b4051d111a 100644 --- a/ly/accordion-defs.ly +++ b/ly/accordion-defs.ly @@ -6,7 +6,7 @@ % 16' = S % -#(primitive-load-path "accordion-script.scm") +\scmfile "accordion-script.scm"; accDiscant = \script "accDiscant" accDiscantF = \script "accDiscantF" diff --git a/ly/params.ly b/ly/params.ly index 96b0057fa8..a3e0eba66c 100644 --- a/ly/params.ly +++ b/ly/params.ly @@ -225,7 +225,7 @@ mmrest_x_minimum = 1.4*\staffheight; % chop off this much when next to pp / ff sign. crescendo_shorten = 4.0 * \interline; crescendo_thickness = \stafflinethickness; -crescendo_height = 1.5 * \interline; +crescendo_height = 0.666 * \interline; % in internote. restcollision_minimum_dist = 3.0; diff --git a/ly/script.ly b/ly/script.ly index 430f31d9ed..38f89853d2 100644 --- a/ly/script.ly +++ b/ly/script.ly @@ -1,5 +1,5 @@ -#(primitive-load-path "script.scm") +\scmfile "script.scm"; "dash-hat" = "marcato" "dash-plus" = "stopped" @@ -44,4 +44,4 @@ prallmordent = \script "prallmordent" upprall = \script "upprall" downprall = \script "downprall" segno = \script "segno" -coda = \script "coda" +coda = \script "coda" \ No newline at end of file diff --git a/make/lilypond.spec.in b/make/lilypond.spec.in index 74c0e642e9..91c6e7ca02 100644 --- a/make/lilypond.spec.in +++ b/make/lilypond.spec.in @@ -22,10 +22,7 @@ Group: Applications/Publishing %description documentation @BLURB@ -The documentation package is rather big, due to the many pictures and -different documentation formats. It is really a rip-off from the -LilyPond website. If you have direct internet access, you may always -read the documentation documentation there: http://www.lilypond.org. +The documentation of LilyPond, both in HTML and PostScript. %prep %setup diff --git a/make/out/lilypond.lsm b/make/out/lilypond.lsm index 2997e73783..e13aa2a544 100644 --- a/make/out/lilypond.lsm +++ b/make/out/lilypond.lsm @@ -1,15 +1,15 @@ Begin3 Title: LilyPond -Version: 1.2.15 -Entered-date: 18OCT99 +Version: 1.2.16 +Entered-date: 21OCT99 Description: Keywords: music notation typesetting midi fonts engraving Author: hanwen@cs.uu.nl (Han-Wen Nienhuys) janneke@gnu.org (Jan Nieuwenhuizen) Maintained-by: hanwen@stack.nl (Han-Wen Nienhuys) Primary-site: sunsite.unc.edu /pub/Linux/apps/sound/convert - 1000k lilypond-1.2.15.tar.gz + 1000k lilypond-1.2.16.tar.gz Original-site: ftp.cs.uu.nl /pub/GNU/LilyPond/development/ - 1000k lilypond-1.2.15.tar.gz + 1000k lilypond-1.2.16.tar.gz Copying-policy: GPL End diff --git a/make/out/lilypond.spec b/make/out/lilypond.spec index 7105c3e1f6..cc796c8485 100644 --- a/make/out/lilypond.spec +++ b/make/out/lilypond.spec @@ -1,9 +1,9 @@ Name: lilypond -Version: 1.2.15 +Version: 1.2.16 Release: 1 Copyright: GPL Group: Applications/Publishing -Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.15.tar.gz +Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.2.16.tar.gz Summary: A program for printing sheet music. URL: http://www.cs.uu.nl/~hanwen/lilypond Packager: Han-Wen Nienhuys @@ -22,10 +22,7 @@ Group: Applications/Publishing %description documentation -The documentation package is rather big, due to the many pictures and -different documentation formats. It is really a rip-off from the -LilyPond website. If you have direct internet access, you may always -read the documentation documentation there: http://www.lilypond.org. +The documentation of LilyPond, both in HTML and PostScript. %prep %setup diff --git a/mutopia/J.S.Bach/Solo-Cello-Suites/allemande-cello.ly b/mutopia/J.S.Bach/Solo-Cello-Suites/allemande-cello.ly index da8e76a773..473a743eca 100644 --- a/mutopia/J.S.Bach/Solo-Cello-Suites/allemande-cello.ly +++ b/mutopia/J.S.Bach/Solo-Cello-Suites/allemande-cello.ly @@ -1,6 +1,5 @@ - \version "1.2.0"; \include "allemande-urtext.ly"; diff --git a/scm/lily.scm b/scm/lily.scm index 8eafa4922a..de49911154 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -8,6 +8,9 @@ ;(debug-enable 'backtrace) ;;; library funtions + +; :use-module (ice-9 regex)) + (define (xnumbers->string l) (string-append diff --git a/scripts/mudela-book.py b/scripts/mudela-book.py index 1328087387..59bde3bbd7 100644 --- a/scripts/mudela-book.py +++ b/scripts/mudela-book.py @@ -682,7 +682,7 @@ def compile_all_files (chunks): system ('lilypond %s %s' % (lilyopts, texfiles)) for e in eps: - cmd = r"""tex %s; dvips -E -o %s %s""" % \ + cmd = r"""tex '\nonstopmode \input %s'; dvips -E -o %s %s""" % \ (e, e + '.eps', e) system (cmd) diff --git a/stepmake/bin/package-diff.py b/stepmake/bin/package-diff.py index 3fc89f375f..927cb0999e 100644 --- a/stepmake/bin/package-diff.py +++ b/stepmake/bin/package-diff.py @@ -52,9 +52,23 @@ def help (): ' -T, --dir-to=TO diff to directory TO\n' ) +def cleanup (): + global from_diff, to_diff, prev_cwd + os.chdir ('/tmp/package-diff') + sys.stderr.write ('Cleaning ... ') + os.system ('rm -fr %s %s' % (from_diff, to_diff)) + sys.stderr.write ('\n') + os.chdir (prev_cwd) + def untar (fn): # os.system ('pwd'); - sys.stderr.write ('untarring ' + fn + '\n') + try: + open (fn) + except: + sys.stderr.write ("Can't find tarball: %s\n" % fn) + cleanup () + sys.exit (1) + sys.stderr.write ("Untarring: %s\n" % fn) os.system ('gzip --quiet -dc ' + fn + '| tar xf - ') sys.stderr.flush () @@ -62,8 +76,13 @@ def remove_automatic (dirnames): files = [] for d in dirnames: - for p in pats: - files = files + find.find (p, d) + try: + for p in pats: + files = files + find.find (p, d) + except: + sys.stderr.write ("Can't find dir: %s\n" % d) + cleanup () + sys.exit (1) dirs = map (lambda d: find.find ('out', d), dirnames) dirs = reduce (lambda x,y: x + y, dirs) @@ -271,10 +290,5 @@ else: os.chdir (to_diff) makediff (from_diff, to_diff, patch_name) -os.chdir ('/tmp/package-diff') -sys.stderr.write ('cleaning ... ') -os.system ('rm -fr %s %s' % (from_diff, to_diff)) -sys.stderr.write ('\n') -os.chdir (prev_cwd) - +cleanup () diff --git a/stepmake/bin/release.py b/stepmake/bin/release.py index 9cad793748..cc6d6ec5ed 100755 --- a/stepmake/bin/release.py +++ b/stepmake/bin/release.py @@ -60,6 +60,7 @@ except: pass os.link(orig, os.path.join (package.release_dir, tarball)) +# urg: howto check exit code? os.system(sys.executable + ' ' + package.topdir + '/stepmake/bin/package-diff.py --package=' + topdir) diffname = pn + '.diff.gz' @@ -67,6 +68,10 @@ rel_pn = package.patch_dir + diffname diffname = os.path.join (outdir, diffname) -os.rename(diffname, rel_pn) +try: + os.rename(diffname, rel_pn) +except: + sys.stderr.write ("Can't find diff: %s\n" % diffname) + sys.exit (1) os.link(rel_pn, diffname) diff --git a/stepmake/stepmake/yolily-toplevel-targets.make b/stepmake/stepmake/yolily-toplevel-targets.make index 72612a2cfb..4de1e45739 100644 --- a/stepmake/stepmake/yolily-toplevel-targets.make +++ b/stepmake/stepmake/yolily-toplevel-targets.make @@ -18,7 +18,7 @@ htmldoc: rm -f `find . -name \*.html~ -print` $(footify-all-command) find `find Documentation -type d -name 'out-www'` -not -name '*dvi' -not -name '*ly' -not -name '*tex' -not -name '*.ps' -not -name 'out-www' > wwwlist - tar cfz $(outdir)/htmldoc.tar.gz `cat wwwlist` `ls *.png out-www/$(distname).diff.gz $(ERRORLOG)` index.html + tar cfz $(outdir)/htmldoc.tar.gz `cat wwwlist` `ls *.png $(ERRORLOG)` index.html localclean: rm -f wwwlist diff --git a/tex/titledefs.tex b/tex/titledefs.tex index 876dff5213..107b523442 100644 --- a/tex/titledefs.tex +++ b/tex/titledefs.tex @@ -25,7 +25,7 @@ \newcommand*{\instrument}[1]{\def\theinstrument{#1}} \newcommand*{\opus}[1]{\def\theopus{#1}} \newcommand*{\piece}[1]{\def\thepiece{#1}} -\newcommand*{\metre}[1]{\def\themetre{#1}} +\newcommand*{\meter}[1]{\def\themeter{#1}} \newcommand*{\poet}[1]{\def\thepoet{#1}} % \newcommand*{\mudelatitle}[1]{\def\thetitle{#1}} @@ -35,8 +35,8 @@ \newcommand*{\mudelainstrument}[1]{\def\theinstrument{#1}} \newcommand*{\mudelaopus}[1]{\def\theopus{#1}} \newcommand*{\mudelapiece}[1]{\def\thepiece{#1}} -\newcommand*{\mudelametre}[1]{\def\themetre{#1}} -\newcommand*{\mudelameter}[1]{\def\themetre{#1}} +\newcommand*{\mudelametre}[1]{\def\themeter{#1}} +\newcommand*{\mudelameter}[1]{\def\themeter{#1}} \newcommand*{\mudelapoet}[1]{\def\thepoet{#1}} % % @@ -53,7 +53,7 @@ \edef\saveparskip{\parskip}\parskip-5mm \begin{minipage}[t]{0.45\textwidth} \ifx\mudelanull\thepoet\else{\thepoet}\\ \fi - \ifx\mudelanull\themetre\else{\themetre}\\ \fi + \ifx\mudelanull\themeter\else{\themeter}\\ \fi \end{minipage}\hspace*{\fill} \begin{minipage}[t]{0.45\textwidth} \begin{flushright}