+1.3.153
+=======
+
+* Some small chord name fixes.
+
+* Added alternative introduction to tutorial; to be merged.
+
+* Reverted simple easy note head function, as some printers seem to
+choke on it (so there are printers that don't use ghostscript?).
+
+* Chord tremolo fixes: shift beams vertically on whole notes. Center
+beams on whole notes. 'beam-gap' had been renamed to 'gap', but only
+for reading.
+
1.3.152.jcn3
============
* Increased number of brace fonts; made size step variable.
-1.3.152.jcn2
+1.3.152.hwn1
============
-* Some small chord name fixes.
+* Add lilypond-init.el
-1.3.151.jcn4
-============
+* Bugfix: flipped octaves on octaviated clefs _8
-* Added alternative introduction to tutorial; to be merged.
+* Prevent dot/flag collisions by lengthening the stem.
-* Reverted simple easy note head function, as some printers seem to
-choke on it (so there are printers that don't use ghostscript?).
+* Bugfix: horizontal shift amount for note collisions.
-* Chord tremolo fixes: shift beams vertically on whole notes. Center beams on whole notes. 'beam-gap' had been renamed to 'gap', but only for reading.
+* Prevent tuplet bracket/staff line collisions
-1.3.152
-=======
+* Bugfix: remove tuplet brackets on automatic beaming.
-1.3.151.uu1
-===========
+* Move development.texi to the WikiWiki.
-1.3.151.jcn2
-============
+1.3.152
+=======
* ly2dvi: changed headsep to 0pt, as old ly2dvi had. Fixes mutopia
textheight setting.
met through music.
- Those deserving special mentioning (in no particular order): Esther,
-Marijke, Heike, Inge, Judith, Hannah, Auke, Ilse, Evelyn, Maartje, Suzanne,
-Ilse (gee, again?), Marieke, Irene, Martine, and last (but
-certainly not least) Janneke!
+ Those deserving special mentioning (in no particular order):
+Esther, Marijke, Heike, Inge, Judith, Hannah, Auke, Ilse, Evelyn,
+Maartje, Suzanne, Ilse (gee, again?), Marieke, Irene, Martine, and
+last (but certainly not least) Janneke!
HWN
<b>Mailing Lists</b>
</td></tr>
<tr><td><font size=-1>
+ <a href="@TOP@Documentation/out-www/index.html#mailing-lists">About the lists</a><br>
<a href="http://mail.gnu.org/mailman/listinfo/gnu-music-discuss/">Discussion</a><br>
<a href="http://mail.gnu.org/mailman/listinfo/help-gnu-music">Help</a><br>
<a href="http://mail.gnu.org/mailman/listinfo/bug-gnu-music/">Bugs</a><br>
@itemize @bullet
+@item @uref{http://mail.gnu.org/mailman/listinfo/gnu-music-discuss,gnu-music-discuss@@gnu.org}
+This list is for discussions concerning LilyPond.
+
+Searchable archives are available from
+@uref{http://www.mail-archive.com/gnu-music-discuss@@gnu.org}.
+
@item @uref{http://mail.gnu.org/mailman/listinfo/info-gnu-music,info-gnu-music@@gnu.org}
is a low-volume list for information on the GNU Music project.
This list is moderated; ask
@email{drl@@gnu.org, David R. Linn} or
@email{hanwen@@cs.uu.nl, Han-Wen} to send announcements for this list.
+
+Searchable archives are available from
+@uref{http://www.mail-archive.com/info-gnu-music@@gnu.org}.
+
@item @uref{http://mail.gnu.org/mailman/listinfo/help-gnu-music,help-gnu-music@@gnu.org}
For help with using LilyPond.
+
+Searchable archives are available from
+@uref{http://www.mail-archive.com/help-gnu-music@@gnu.org}.
+
@item @uref{http://mail.gnu.org/mailman/listinfo/bug-gnu-music,bug-gnu-music@@gnu.org}
If you have bugreports, you should send them to this list.
-
Please include in your bugreport the version of LilyPond that
you experience the problem with, a description of your system and sample
input to reproduce the problem. Do not send output files over the list,
they tend to be very big and don't help with describing the problem.
-@item @uref{http://mail.gnu.org/mailman/listinfo/gnu-music-discuss,gnu-music-discuss@@gnu.org}
- For discussions concerning LilyPond.
+Searchable archives are available from
+@uref{http://www.mail-archive.com/bug-gnu-music@@gnu.org}.
+
@end itemize
These pages were entirely created from a @strong{development snapshot}
@lilypondfile[printfilename]{tie-accidental.ly}
-
@lilypondfile[printfilename]{tup.ly}
+@lilypondfile[printfilename]{tuplet-beam.ly}
+
+@lilypondfile[printfilename]{tuplet-staffline-collision.ly}
+
@section Property details
@subsection Red Hat Linux
Red Hat 7.0 i386 RPMS are available from
-@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/RedHat/}.
+@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/}.
You can also compile them yourself. A spec file is in
@file{make/out/redhat.spec}. This file is distributed along with the
sources. You can make the rpm by issuing
@example
- rpm -tb lilypond-x.y.z.tar.gz
+ tar xfz lilypond-x.y.z.tar.gz
+ rpm -bb lilypond-x.y.z/make/out/redhat.spec
rpm -i /usr/src/redhat/RPMS/i386/lilypond-x.y.z
-
+
@end example
For running on a Red Hat system you need these packages: guile, tetex,
guile-devel, flex, bison, texinfo, tetex-devel, groff,
libgr-progs.
+
+@b{Warning}
+
+There appears to be a problem with the Xdvi shipped with RedHat
+7.1. Symptoms: Xdvi responds very sluggishly or hangs while viewing
+lilypond output. The cause for this problem is unknown; you are advised
+to recompile Xdvi from source.
+
+@subsection LinuxPPC
+
+
+Some LinuxPPC RPMS should available from
+@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/}.
+
+A LinuxPPC RPM can be made using the @file{redhat.spec} file.
+
@subsection SuSE
-You can also compile them yourself. A spec file is in
-@file{make/out/suse.spec}. This file is distributed along with the
-sources.
+Some SUSE RPMS should available from
+@uref{ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/}.
+
+You can also compile a RPM for SUSE yourself. A spec file is in
+@file{make/out/suse.spec}, see the instructions for building the RedHat
+RPM.
You must have the following packages: guile tcsh tetex te_latex te_kpath
te_mpost libpng python gpp libgpp gettext autoconf netpbm libnetpb
@subsection Slackware
+No precompiled packages for Slackware are available.
+
Problems have been reported with Slackware 7.0; apparently, it ships
with a faulty compiler. Do not compile LilyPond with -O2 on this
platform.
@subsection Mandrake
-[TODO]
+Some binaries are available at rpmfind.net. Refer to
+@uref{ftp://ftp.rpmfind.net/linux/Mandrake-devel/cooker/contrib/RPMS/}.
+
@subsection Debian GNU/Linux
@unnumberedsec What is LilyPond? What can it do for you?
-LilyPond prints music notation. It produces beautiful sheet music from
+LilyPond prints beautiful sheet music. It produces music notation from
a description file. It excels at typesetting classical music, but you
can also print pop-songs.
HTML_FILES = $(addprefix $(outdir)/, $(TELY_FILES:.tely=.html))
-PS_FILES = $(DVI_FILES:.dvi=.ps) $(OUTDOC_FILES:.doc=.ps) $(OUTTEX_FILES:.tex=.ps)
+PS_FILES = $(DVI_FILES:.dvi=.ps)
PS_GZ_FILES= $(addsuffix .gz, $(PS_FILES))
-@c -*-texinfo-*-
-
-@c Move chapter
-
-@node Development
-@chapter Development
-
-@menu
-* CodingStyle::
-* Making patches::
-* Localisation::
-* Helping with development::
-* ETF format::
-@end menu
-
-@node CodingStyle
-@section CodingStyle - standards while programming for GNU LilyPond
-
-As a general rule, you should always try to continue computations, even
-if there is some kind of error. When the program stops, it is often very
-hard for a user to pinpoint what part of the input causes an
-error. Finding the culprit is much easier if there is some viewable
-output.
-
-So functions and methods do not return errorcodes, they never crash, but
-report a programming_error and try to carry on.
-
-@unnumberedsubsec Languages
-
-C++ and Python are preferred. 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 is coded in @file{class-name.*}
-
-@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
-
-Macro names should be written in uppercase completely.
-
-@unnumberedsubsec Broken code
-
-Try not to write broken code. This includes hardwired dependencies,
-hardwired constants, slow algorithms and obvious limitations. If you can
-not avoid it, mark the place clearly, and add a comment explaining
-shortcomings of the code.
-
-@unnumberedsec Hungarian notation naming convention
-
-The C++ part of LilyPond uses 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 @code
-@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.
- */
- 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 @code
-@item @code{a}
- array
-@item @code{arr}
- user built array.
-@item @code{c}
- const. Note that the proper order is @code{Type const}
- and not @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 @code
-@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<int*> 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
-@section Making patches
-
-@unnumberedsec 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
- 0.1.73.jcn1
- ===========
-
- * A concise, yet clearly readable description of what changed.
-
-@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
-
-@unnumberedsec Applying patches
-
-[outdated: please use xdeltas]
-
-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
-
-@node Localisation
-@section Localisation - User messages in LilyPond
-
-This document provides some guidelines for uniformising user messages.
-In the absence of other standards, we'll be using these rules when coding
- for LilyPond. Hopefully, this can be replaced by general GNU
-guidelines in the future.
-
-Not-preferred messages are marked with @code{+}. By convention,
-agrammatical examples are marked with @code{*}.
-
-@subsection Guidelines
-
-@itemize @bullet
-
-@item
-Every message to the user should be localised (and thus be marked
-for localisation). This includes warning and error messages.
-
-@item
-Don't localise/gettextify:
-
-@itemize @minus
-@item @code{programming_error ()}s
-@item @code{programming_warning ()}s
-@item debug strings
-@item output strings (PostScript, TeX)
-@end itemize
-
-@item
-Messages to be localised must be encapsulated in @code{_ (STRING)}
-or @code{_f (FORMAT, ...)}. Eg:
-
-@example
-warning (_ ("Need music in a score"));
-error (_f ("Can't open file: `%s'", file_name));
-@end example
-
-In some rare cases you may need to call @code{gettext ()} by hand.
-This happens when you pre-define (a list of) string constants for later
-use. In that case, you'll probably also need to mark these string
-constants for translation, using @code{_i (STRING)}. The @code{_i}
-macro is a no-op, it only serves as a marker for @file{xgettext}.
-
-@example
-char const* messages[] = @{
- _i ("enable debugging output"),
- _i ("ignore lilypond version"),
- 0
-@};
-
-void
-foo (int i)
-@{
- puts (gettext (messages [i]));
-@}
-@end example
-
-See also
-@file{flower/getopt-long.cc} and @file{lily/main.cc}.
-
-@item
-Don't use leading or trailing whitespace in messages.
-
-@item
-Messages containing a final verb, or a gerund (@code{-ing}-form)
-always start with a capital. Other (simpler) messages start with
-a lowercase letter:
-
-@example
-The word `foo' is not declared.
-`foo': not declared.
-Not declaring: `foo'.
-@end example
-
-@item
-To avoid having a number of different messages for the same situation,
-we'll use quoting like this @code{"message: `%s'"} for all strings.
-Numbers are not quoted:
-
-@example
-_f ("Can't open file: `%s'", name_str)
-_f ("Can't find charater number: %d", i)
-@end example
-
-@item
-Think about translation issues. In a lot of cases, it is better to
-translate a whole message. The english grammar mustn't be imposed on
-the translator. So, iso
-
-@example
-_ ("Stem at ") + moment.str () + _(" doen't fit in beam")
-@end example
-
-@noindent
-have
-
-@example
-_f ("Stem at %s doen't fit in beam", moment.str ())
-@end example
-
-@item
-Split up multi-sentence messages, whenever possible. Instead of
-
-@example
-warning (_f ("out of tune! Can't find: `%s', "Key_engraver"));
-
-warning (_f ("Can't find font `%s', loading default",
- font_name));
-@end example
-
-@noindent
-rather say:
-
-@example
-warning (_ ("out of tune:");
-warning (_f ("Can't find: `%s', "Key_engraver"));
-
-warning (_f ("Can't find font: `%s', font_name));
-warning (_f ("Loading default font"));
-@end example
-
-@item
-If you must have multiple-sentence messages, use full punctuation.
-Use two spaces after end of sentence punctuation.
-No punctuation (esp. period) is used at the end of simple messages.
-
-@example
- _f ("Non-matching braces in text `%s', adding braces", text)
- _ ("Debug output disabled. Compiled with NPRINT.")
- _f ("Huh? Not a Request: `%s'. Ignoring.", request)
-@end example
-
-@item
-Don't modularise too much; a lot of words cannot be translated
-without context.
-It's probably safe to treat most occurences of words like
-stem, beam, crescendo as separately translatable words.
-
-@item
-When translating, it is preferrable to put interesting information
-at the end of the message, rather than embedded in the middle.
-This especially applies to frequently used messages, even if this
-would mean sacrificing a bit of eloquency. This holds for original
-messages too, of course.
-
-@example
- en: can't open: `foo.ly'
-+ nl: kan `foo.ly' niet openen (1)
- kan niet openen: `foo.ly'* (2)
- niet te openen: `foo.ly'* (3)
-@end example
-
-The first nl message, although gramatically and stylishly correct,
-is not friendly for parsing by humans (even if they speak dutch).
-I guess we'd prefer something like (2) or (3).
-
-@item
-Please don't run make po/po-update with GNU gettext < 0.10.35
-
-@end itemize
-
-@node Helping with development
-@section Getting involved
-
-If you want to help developing LilyPond your efforts are appreciated.
-You can help LilyPond in several ways. Not all tasks requiring
-programming or understanding the full source code.
-
-Please don't expect us to give you instructions on what you should
-do. We're just a bunch of simple hackers, and we're absolutely
-incompetent about management, design in advance, delegating work.
-Some people write to us "I want to help, what should I do?", but we
-never know what to answer them.
-
-If you want to hack, just start hacking. You can send us the result as
-a patch, and we'll gladly incorporate it.
-
-If you need some hints on where to get started: there are a number of
-specific areas where you could do work.
-
-@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 (either
-by hand, or by converting from scans or MIDI) and submitting it. Point
-your browser to the @uref{http://sca.uwaterloo.ca/Mutopia, Mutopia
-webpage}.
-
-@unnumberedsubsec Writers
-
-The documentation of LilyPond and related utilities needs a lot of
-work. The documentation is written in
-@uref{http://www.gnu.org/software/texinfo,texinfo}. The documentation of
-LilyPond is sorely lacking in terms of completeness, depth and
-organisation.
-
-Write if you know how to write english documentation in texinfo, and
-know about music and music notation. You must also know how to use
-LilyPond (or be prepared to learn using it). The task is not especially
-hard, but it is a lot of work, and you must be familiar with LilyPond.
-
-@unnumberedsubsec Translators
-
-LilyPond is completely ready for internationalized messages, but there
-are only a few translations so far (dutch, italian, german, japanese,
-french, russian). Translation involves writing a .po file, which is
-relatively easy, and does not even require running LilyPond.
-
-@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 our
-TODO file, listed on the homepage of Jan and
-@uref{http://www.cs.uu.nl/~hanwen/lily-devel,Han-Wen}. Modifying
-LilyPond almost always requires patches to the C++ part.
-
-If you still don't have any idea what to do, you might want to browse
-the mailing lists; Users do lots of feature requests, and you could
-implement any of them.
-
-
-There are also numerous other interesting projects that are more or less
-related to LilyPond
-
-@itemize @bullet
-@item Writing converters, eg. from NIFF and MIDI (we tried writing one with
-limited success: midi2ly, included with lilypond.)
-
-We found that writing them in Python is the easiest.
-
-@item Writing a GUI frontend to
-LilyPond. At the moment @uref{denemo,denemo.sourceforge.net} is the most
-advanced.
-
-@item Helping write @uref{http://solfege.sourceforge.net/,solfege
-tools}
-
-@item Helping @uref{primrose.sourceforge.net,primrose}, a tool for
-scanning sheet music.
-@end itemize
-
-@node ETF format
-@section An incomplete description of the Enigma Transport Format
-
-Enigma Transport Format (ETF for short) is a format designed by Coda music
-technology, and it is used in the proprietary notation package
-Finale. Since it is very poorly documented, I'll attempt some
-documentation here.
-
-ETF is an memory dump where object pointers have been replaced by object
-numbers. The numbers are larger than 0 and the number 0 is used to
-denote the nil pointer. The dump is encoded in ASCII (where the mac
-version uses CR, and the PC CR/LF as line delimiters)
-
-A file is divided into sections like this
-
-@example
-^section-header
-DATA
-^section-header
-DATA
-
-(etc.)
-@end example
-
-@var{DATA} is stored in the form of tagged lines, where a tagged line looks
-like
-
-@example
-^TG(N1[,N2]) X1 X2 X3 (etc)
-@end example
-
-The caret is at the start of the line, @code{TG} is a two letter tag,
-and @var{N1} (and optionally @var{N2}) are numbers identifying the
-object to be described. @var{X3}, @var{X4} etc contain data in the form
-of either a signed 16 bit number, or a 32 bit number (in hex, with a $
-sign prepended). The number of Xs per line for a certain tag is
-constant.
-
-The numbers in @code{N1} need not be consecutive or ascending, mostly.
-
-
-If an object is too large to fit on a single line (which typically has
-only five X's), it is put on multiple lines and padded with zero's, eg.
-
-@example
-^GF(1,2) 3 0 1 2 3
-^GF(1,2) 4 0 0 0 0
-@end example
-
-(the GF object requires 6 16 bit words, hence the 4 padding zeroes).
-
-Note structure:
-
-Each staff can contain up to four layers, where a layer correspond to a
-horizontal `line' of notes. Each layer is broken up into frames, where
-each frame is one measure of a layer.
-
-@example
- ^GF(s,m) @var{c} @var{flags} @var{f1} @var{f2} @var{f3}
- ^GF(s,m) @var{f4} 0 0 0 0
-@end example
-
-Here @var{s} is the staff number, @var{m} the measure number,
-@var{flags} is a 16-bit bit-vector, and @var{f1} to @var{f4} are frame
-identifiers. @var{c} is a clef-identifier.
-
-There is a second variant of the @code{GF} tag, which has only one line;
-it looks like
-
-@example
- ^GF(s,m) @var{fr} @var{c} @var{x} @var{y} @var{z}
-@end example
-
-here, @code{fr} is a frame number, @code{c} the clef number. The
-function of x, y , z is unknown.
-
-A frame is described by the FR tag
-
-@example
- ^FR(@var{n}) @var{n1} @var{n2} 0 0
-@end example
-
-This means frame number @var{n} runs from note @var{n1} to note @var{n2}
-Where `running from' is interpreted as ``that part of a linked note list
-that starts with note @var{n1} and ends with note @var{n2}''. This is
-something different from the sequence of notes
-@var{n1}, @var{n1 + 1} , ... , @var{n2 - 1}, @var{n2}.
-
-Notes (or more accurately chord-notes/rests) are described as follows:
-
-@example
- ^eE(@var{n}) @var{l1 l2 dur pos $flags extflags pitchcount}
- pitchrecords
-@end example
-
-This is note number @var{n} (in list where @var{l1} and @var{l2} are
-previous and next).
-
-Durations are stored as a number where 1024 is the quarter note, 512 the
-eighth, etc. Dotted notes are stored by multiplying the dur field
-appropriately.
-
-pitchcount is the number of pitch records. Each pitchrecord looks like
-@example
- pitch $flags
-@end example
-(note that the line starts with spaces, and not with a caret)
-
-
-pitch is a 16 bit number, where the lower order 4-bits is a signed
-nybble which adds an alteration (0 = natural, 1 = sharp, etc.)
-The remaining 12 bits encodes the note-name (octave inclusive.)
-
-Both the alteration and the note-name are relative to the scale as
-defined by the key-signature in this measure. The person who invented
-this should have his head checked out.
-
-The key and time signature are defined in the MS field
-@example
- ^MS(n) space key beats beatlen y z
-@end example
-
-@var{n} is the measure number. @var{space} is the width of the
-measure (?), @var{key} the number of the keysignature (0 = C major, 1 G
-major, etc. 255 = F major, 254 = Bflat major). beats and beatlen
-determine time signature.
-
-Key and time are determined score wide. The mind boggles at how they
-plan to do polytonal and polymetric music. And how do they do
-mid-measure keychanges?
-
-Slurs are (among others) stored with an Sx tag
-
-@example
- ^Sx(@var{slurnumber}) @var{stuff}
-@end example
-
-The slur has many parameters. The 6th number on the first line is the
-starting note, the 3rd number on the 4th line the ending note.
-
-
-Some other information can be found in the Finale Plug-in Development
-(there is a vague manual, and some source files that are useful).
-
-You can download the PDK from Coda's website,
-@uref{http://www.codamusic.com/coda/Fin2000_pdk_download.asp}. You do
-need to register as a user (you can also do it if you have never bought
-an coda product).
-
-
-More tags:
-@example
-RU - repeat
-ES - end repeat
-ET - end repeat text
-BR - backw repeat
-mt - measure text
-pT - page text
-TX - text blocks
-SD - shape
-DY - score expr
-AC - tempo
-GF - clef
-IS - staff spec
-DO (shape expression),
-DT (text expression),
-IK (chord playback),
-IS (staff spec),
-IV (chord suffix),
-IX (articulation definition - documented in edata.h),
-Iu (instrument used - documented in edata.h),
-LA (layer preferences - documented in eprfdata.h),
-MN (measure number region),
-MS (measure spec),
-PS (page spec),
-RS (repeat style - documented in edata.h),
-RT (text repeat style text - documented in edata.h),
-SD (shape),
-SS (staff system spec),
-TX (text block),
-pT (page text)
-
-TP - tuplet
-
-sl - slur shapetag
-@end example
-
-
@lilypond[13pt,eps]
\property Score.barNonAuto = ##t
-\property Lyrics.LyricText \set #'font-style = #'large
-\property Voice.TextScript \set #'font-style = #'large
+\property Score.LyricText \set #'font-style = #'large
+\property Score.TextScript \set #'font-style = #'large
\addlyrics
-\notes\relative c' {
+ \context Staff \notes\relative c' {
c1 d
\property Voice.TextScript \set #'padding = #-10
e^"~~ S" f g a
I: coda (uncinata), bandiera, F: crochet, D: Fahne, F@"ahnchen, NL: vlaggetje,
DK: fane, S: flagga, N: .
-Ornament at the end of the stem of a note used for notes with values less than
-a quarter note. The number of flags determines the @w{@ar{}@strong{note value}}.
+Ornament at the end of the stem of a note used for notes with values
+less than a quarter note. The number of flags determines the
+@w{@ar{}@strong{note value}}.
@lilypond[13pt,eps]
@node First steps
@section First steps
-Let's try to explain this example:
-
-The basics of any piece of music are notes.Notes are entered
-with letters @code{a} to @code{g} followed by a
+The basics of any piece of music are notes. Notes are entered
+with letters @code{a} to @code{g}, followed by a
number that represents the duration: a @code{2} is a half note, a
-@code{4} is a quarter note. A period is used for augmentation dots, so
+@code{4} is a quarter note. A period adds a dot to the note, so
entering @code{2.} gives a dotted half note.
@example
c2 e4 g2.
@lilypond[fragment]
\time 3/4
\clef bass
- s2._" "
+ s2_" "
@end lilypond
The commands together with the notes are combined to form a snippet of
This snippet is ready to be printed. This is done by combining the music
with a printing command. The printing command is the so-called
-@code{\paper} block. The music and paper block are combined by
-enclosing them in @code{\score}.
+@code{\paper} block. You will see later that the \paper block is
+necessary to customize all kinds of printing specifics. The music and
+paper block are combined by enclosing them in @code{\score}.
@lilypond[verbatim]
\score {
don't have to be marked explicitly. You just enter the pitch, and
LilyPond determines wether or not to print an accidental.
-Managing larger pieces.
-
If you look at the last piece, it is already apparent that entering
octaves using quotes is not very convenient. A score written in high
register will be encoded using lots quotes. This makes the input file
are used to mark large jumps in the melody. Without any quotes or
commas, the interval between a note and its predecessor is assumed to be
a fourth or less. Quotes and commas add octaves in up and down
-direction. Relative octaves are introduced by @code{\relative} followed
-by a starting pitch
+direction.
@lilypond[fragment,verbatim]
\relative c'' { c4 d4 b4 e4 a,4 f'4 g,4 a'4 }
@end lilypond
+You can enter a piece in relative mode, by putting @code{\relative} in
+front. You also have to enter a starting pitch, in this case @code{c''}.
+
Slurs (not to be confused with ties) are entered with parentheses. You
mark the starting note and ending note with a @code{(} and a
@code{)} respectively.
-@lilypond[fragment,relative 2, verbatim]
+@lilypond[fragment,relative 1, verbatim]
c8( cis d ) e
@end lilypond
If you need two slurs at the same time (one for articulation, one for
-phrasing), you can also make phrasing slurs with @code{\(} and
+phrasing), you can also make a phrasing slur with @code{\(} and
@code{\)}.
@c lousy example
\context Staff = staffB { \clef bass c }
>
@end lilypond
-Here, @code{staffA} and @code{staffB} are names that you give to the
-staff. For now, it doesn't matter what names you give, as long as they
-are different.
+Here, @code{staffA} and @code{staffB} are names that you give them to
+the staff. For now, it doesn't matter what names you give them, as long
+as they are different.
We can typeset a melody with two staffs now:
(the top staff), but is printed on both. LilyPond knows that the time
signature should be the same for all staffs.
-[TODO add some more here
+Dynamic signs are made by adding the markings after the note
+@lilypond[verbatim,relative 1]
+c-\ff c-\mf
+@end lilypond
+
+Crescendi are started with the commands @code{\<} and @code{\>}. The
+command @code{\!} finishes a crescendo on the following.
+@lilypond[verbatim,relative 1]
+c2 \< \! c2-\ff \> c2 \! c2
+@end lilypond
+
+Chords can be made by surrounding notes with @code{<} and @code{>}:
+@lilypond[relative 0, fragment,verbatim]
+ r4 <c e g> <c f a>
+@end lilypond
+
+@c te diepzinnig?
+
+In general, @code{ < @var{stuff} > } is used when @var{stuff} all
+happens at the same time, like in chords, or (like in the two-staff
+example above) in a bunch of stacked staffs.
+
+Of course, you can combine beams and ties with chords:
+@lilypond[relative 0, fragment,verbatim]
+ r4 [<c8 e g> <c8 f a>] ~ <c8 f a>
+@end lilypond
+
+When you want to combine chords with slurs and dynamics, an annoying
+technical detail crops up: you have type these commands next to the
+notes, which means that they have to be inside the @code{< >}:
+
+@lilypond[relative 0, fragment,verbatim]
+ r4 <c8 e g \> ( > <c e g> <c e g> < ) \! c8 f a>
+@end lilypond
+
+A nasty technical detail also crops up when you start a score with a
+chord:
+@lilypond[verbatim,singleline]
+\score { \notes <c'1 e'1> }
+@end lilypond
+The program can not guess that you want the notes on only one staff. To
+force the chord on a staff, add @code{\context Staff} like this:
+@lilypond[verbatim,singleline]
+\score { \notes \context Staff <c'1 e'1> }
+@end lilypond
-* \header
-* dynamics , articulation
-* <chords>
+@ignore
+[TODO add some more here
+
+* lyrics, chords (?)
+
+* \header
* identifiers?
]
+@end ignore
-This is the end of the simple tutorial. What follows is also a manual in
-tutorial-style, but it is much more in-depth, and alas more
-intimidating. You should read it if you want to know about the more
-advanced features of lilypond, such as producing orchestral scores and
-parts, fine tuning output, writing polyphonic music, etc.
+This is the end of the simple tutorial. You know the basic ingredients
+of a music file, so this is the right moment to try your at hand at
+doing it yourself: try to type some simple examples, and experiment a
+little.
+
+When you're comfortable with the basics, then you might want to read the
+rest of this chapter. It also a manual in tutorial-style, but it is much
+more in-depth. It will also be very intimidating if you're not familiar
+with the basics. It deals with some of the more advanced features of
+lilypond. Topics include lyrics, chords, orchestral scores and parts,
+fine tuning output, polyphonic music, and integrating text and music.
subdirectory @file{input/tutorial/}@footnote{When we refer to filenames,
they are relative to the top directory of the source package. }
-
To demonstrate what LilyPond input looks like, we start off with a
full-fledged, yet simple example. It is a convoluted version
of the famous minuet in J. S. Bach's @emph{Klavierb@"uchlein}. The file
% all text after a percent sign is a comment
% and is ignored by Lilypond
@end example
-The percent sign, @code{%}, introduces a line comment. You can also
-comment out a block of several lines, by enclosing them in
-@code{%@{} and @code{%@}}.
+Percent signs introduce comments: everything after a percent sign is
+ignored. You can use this to write down mental notes to yourself. You
+can also make longer comments by enclosing text in @code{%@{} and
+@code{%@}}.
@cindex comment
@cindex block comment
@cindex line comment
@cindex @code{\include}
@cindex point, printer's
@cindex staff size setting
-By default, LilyPond will typeset the music in a size such that each
-staff is 20 point@footnote{A point is the standard measure of length for
-printing; one point is 1/72.27 inch.} high. We want smaller
-output (16 point staff height), so we must import the settings for that
-size, which is done here.
+By default, LilyPond will typeset the music in a size such that each
+staff is 20 point (0.7 cm, or 0.27 inch) high. We want smaller output
+(16 point staff height), so we must import the settings for that size,
+which is done here.
@separate
@example
@end example
@cindex augmentation dot
-@cindex dot
-A period adds an augmentation dot to the note.
+@cindex dotted note
+A period adds a dot to the note.
@separate
@example
@example
\version "1.3.124"
-\header @{ title = "Two miniatures" @}
+\header @{
+ title = "Two miniatures"
+ tagline = "small is beautiful"
+@}
#(set! point-and-click line-column-location)
@end lilypond
This file is produced by ly2dvi in a few stages, with the help of text
-formatting tools. LilyPond produces two output files, @file{miniatures.tex}
-and @file{miniatures-1.tex}. They both look like this:
-
-@example
- ...
- \placebox@{-5 \outputscale @}%
- @{ 8.7229 \outputscale @}%
- @{\magfontWXGEomMMBo\char90 @}%
-
- \placebox@{-4 \outputscale @}%
- @{ 81.0647 \outputscale @}%
- ...
-@end example
-
-@file{ly2dvi} looks at what output LilyPond produces, and generates a
-file called @file{ly2dvi.out.tex}. This file contains formatting
-instructions for the title and page layout. A fragment might look like
-
-@example
-
- \def\lilypondopus@{Opus 1.@}
- \def\lilypondpiece@{Up@}
- \def\mustmakelilypondtitle@{@}
- \input miniatures.tex
- \def\lilypondtitle@{Two miniatures@}
-
-@end example
-
-@file{ly2dvi} runs it through LaTeX. LaTeX is a text-formatting system
-built on top of @TeX{}. It's very popular in the academic world. If LaTeX
-is successful, this will produce a @file{.dvi} file, containing both the
-titling and the actual music. @code{ly2dvi} completes its task by
-deleting the two temporary files, leaving only @file{miniatures.dvi}.
+formatting tools. LilyPond produces two output files,
+@file{miniatures.tex} and @file{miniatures-1.tex}. Both files contain
+only graphical music notation. @file{ly2dvi} looks at what output
+LilyPond produces, and adds page layout and titling to those files. The
+result is a DVI file called @file{miniatures.dvi}.
Next, now we'll look at the example line by line to explain new things.
@separate
@example
- \header @{ title = "Two miniatures" @}
+ \header @{
+ title = "Two miniatures" @}
@end example
This sets the titling information for the entire file.
-
+@separate
+@example
+ tagline = "small is beautiful"
+@end example
+A signature line is printed at the bottom of the last page.
+ This signature is produced from the @code{tagline} field of
+@code{\header}. Many people find the default "Lily was here,
+@var{version number}" too droll. If that is the case, assign
+something else to @code{tagline}, as shown above.
@separate
@example
#(set! point-and-click line-column-location)
large files: if you're digitizing existing music, you have to
synchronize the .ly file, the sheet music on your lap and the sheet
music on the screen. The point-and-click mechanism makes it easy to
-find the origin of an error in the .ly file: when you view the file with
+find the origin of an error in the LY file: when you view the file with
Xdvi and click on a note, your editor will jump to the spot where that
note was entered. For more information, see @ref{Point and click}.
When you're copying music from existing sheet music, relative octaves
are probably the easiest to use: it's less typing work and errors are
-easily spotted. However, if you write LilyPond input, either by hand
-(ie. composing) or by computer, absolute octaves are probably less work.
+easily spotted. However, if you write LilyPond input directly, either by
+hand (i.e. composing) or by computer, absolute octaves are easier to use.
@separate
That's all folks. From here, you can either try fiddling with input
files, or you can read the reference manual. You can find more example
files in @file{input} and @file{input/test}. You can also look at some
-real music. Have a look at the @uref{Mutopia project,
-http://www.mutopiaproject.org}.
+real music. The website @uref{http://www.mutopiaproject.org} has many
+examples of real music typeset by LilyPond.
README_FILES = DEDICATION COPYING NEWS CHANGES ROADMAP
README_TXT_FILES = AUTHORS.txt README.txt INSTALL.txt FAQ.txt
IN_FILES := $(wildcard *.in)
-EXTRA_DIST_FILES = lilypond-font-lock.el lilypond-mode.el vimrc VERSION $(README_FILES) $(SCRIPTS) $(IN_FILES) emacsclient.patch mktexnam.patch
+EXTRA_DIST_FILES = lilypond-font-lock.el lilypond-mode.el lilypond-init.el vimrc VERSION $(README_FILES) $(SCRIPTS) $(IN_FILES) emacsclient.patch
NON_ESSENTIAL_DIST_FILES = $(README_TXT_FILES)
INSTALLATION_DIR=$(datadir)
INSTALLATION_FILES=$(configuration) VERSION
Emacs mode
Compiling for distributions
Red Hat Linux
+ LinuxPPC
SuSE
Slackware
Mandrake
-------------
Red Hat 7.0 i386 RPMS are available from
-`ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/RedHat/'.
+`ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/'.
You can also compile them yourself. A spec file is in
`make/out/redhat.spec'. This file is distributed along with the
sources. You can make the rpm by issuing
- rpm -tb lilypond-x.y.z.tar.gz
+ tar xfz lilypond-x.y.z.tar.gz
+ rpm -bb lilypond-x.y.z/make/out/redhat.spec
rpm -i /usr/src/redhat/RPMS/i386/lilypond-x.y.z
For running on a Red Hat system you need these packages: guile,
libstdc++-devel, guile-devel, flex, bison, texinfo, tetex-devel, groff,
libgr-progs.
+ Warning
+
+ There appears to be a problem with the Xdvi shipped with RedHat 7.1.
+Symptoms: Xdvi responds very sluggishly or hangs while viewing lilypond
+output. The cause for this problem is unknown; you are advised to
+recompile Xdvi from source.
+
+LinuxPPC
+--------
+
+ Some LinuxPPC RPMS should available from
+`ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/'.
+
+ A LinuxPPC RPM can be made using the `redhat.spec' file.
+
SuSE
----
- You can also compile them yourself. A spec file is in
-`make/out/suse.spec'. This file is distributed along with the sources.
+ Some SUSE RPMS should available from
+`ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/binaries/'.
+
+ You can also compile a RPM for SUSE yourself. A spec file is in
+`make/out/suse.spec', see the instructions for building the RedHat RPM.
You must have the following packages: guile tcsh tetex te_latex
te_kpath te_mpost libpng python gpp libgpp gettext autoconf netpbm
Slackware
---------
+ No precompiled packages for Slackware are available.
+
Problems have been reported with Slackware 7.0; apparently, it ships
with a faulty compiler. Do not compile LilyPond with -O2 on this
platform.
Mandrake
--------
- [TODO]
+ Some binaries are available at rpmfind.net. Refer to
+`ftp://ftp.rpmfind.net/linux/Mandrake-devel/cooker/contrib/RPMS/'.
Debian GNU/Linux
----------------
PACKAGE_NAME=LilyPond
MAJOR_VERSION=1
MINOR_VERSION=3
-PATCH_LEVEL=152
-MY_PATCH_LEVEL=jcn3
+PATCH_LEVEL=153
+MY_PATCH_LEVEL=
# use the above to send patches: MY_PATCH_LEVEL is always empty for a
# released version.
+lilypond (1.3.150-1) unstable; urgency=low
+
+ * New upstream version.
+ * Renamed package from lilypond1.3 back to lilypond.
+ This also fixes a lot of bugs from the old lilypond-1.2.17 package.
+ lilypond1.3 is temporarily provided as a dummy transitional package.
+ Closes: Bug#67697, 84352, 48731, 72223, 85834.
+ * [debian/rules]:
+ - No longer blindly copy intermediate DVI files into
+ the deb package. Thanks to Daniel Burrows for the reminder.
+ Closes: Bug#87852.
+ - Added "export MODE=ljfour" and "export BDPI=600" because I use
+ something different in my local /etc/texmf/mktex.cnf and that
+ broke the build.
+ * Fixed Build-Depends because pnmtopng has been merged into the netpbm
+ package. Thanks to Adrian Bunk for the notice. Closes: Bug#93961.
+ * [lily/kpath.cc]: Modified to better conform to web2c fontpath policy.
+
+ -- Anthony Fok <foka@debian.org> Thu, 26 Apr 2001 03:25:50 -0600
+
lilypond1.3 (1.3.132-1) unstable; urgency=medium
* New upstream version.
-Source: lilypond1.3
-Build-Depends: debhelper (>= 2.0.72), python-base (>= 1.5.2-4), libguile-dev (>= 1:1.4-9), tetex-bin, libkpathsea-dev, tetex-extra, flex, bison, texinfo (>= 4.0-1), bibtex2html, groff, gs, netpbm, pnmtopng, m4, gettext (>= 0.10.35-13)
+Source: lilypond
+Build-Depends: debhelper (>= 3.0.5), python-base (>= 1.5.2-4), libguile-dev (>= 1:1.4-9), tetex-bin, libkpathsea-dev, tetex-extra, flex, bison, texinfo (>= 4.0-1), bibtex2html, groff, gs, netpbm (>= 2:9.10-1), m4, gettext (>= 0.10.36-1)
Build-Conflicts: lilypond, lilypond1.3
Section: tex
Priority: optional
Maintainer: Anthony Fok <foka@debian.org>
-Standards-Version: 3.2.1
+Standards-Version: 3.5.2
-Package: lilypond1.3
+Package: lilypond
Architecture: any
-Replaces: lilypond
-Provides: lilypond
-Depends: ${shlibs:Depends}, tetex-bin (>= 1.0.5-1), python-base (>= 1.5.2-4), guile1.4
+Replaces: lilypond1.3
+Provides: lilypond1.3
+Depends: ${shlibs:Depends}, tetex-bin (>= 1.0.5-1), python-base (>= 1.5.2-4), guile
Recommends: tetex-extra (>= 1.0-1)
-Conflicts: lilypond, musixtex-fonts
+Conflicts: lilypond, lilypond1.3 (<= 1.3.132-1), musixtex-fonts
Description: A program for printing sheet music.
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.
- .
- This is the developmental 1.3 branch of LilyPond. It is not intended for
- use with stable projects, although 1.3.x is most likely to be less buggy
- and much more featureful than then the old "stable" 1.2.17.
.
URLs: http://www.cs.uu.nl/~hanwen/lilypond/
http://www.xs4all.nl/~jantien/lilypond/
http://www.lilypond.org/
Authors: Han-Wen Nienhuys <hanwen@cs.uu.nl>
Jan Nieuwenhuizen <janneke@gnu.org>
+
+Package: lilypond1.3
+Architecture: all
+Depends: lilypond (>= 1.3.150-1)
+Description: Dummy package for transition to new stable lilypond.
+ This dummy package provides a transition from the previous lilypond1.3
+ package back to a newer lilypond because the 1.3.x series will become
+ 1.4 really soon now.
+ .
+ Please feel free to remove this dummy package after you have upgraded
+ to the latest lilypond.
This package was Debianized by Anthony Fok <foka@debian.org> on
Wed, 6 Aug 1997 04:30:28 -0600
-The development branch, lilypond1.3, is packaged separately
+The development branch, lilypond1.3, was packaged separately
on Tue, 9 Nov 1999 22:30:32 -0700
+but was merged back into the lilypond package
+as of Mon, 16 Apr 2001 21:58:42 -0600
It was downloaded from
- ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/v1.3/
+ ftp://ftp.lilypond.org/pub/LilyPond/v1.3/
It is also available at:
- ftp://ftp.lilypond.org/pub/LilyPond/v1.3/
+ ftp://ftp.cs.uu.nl/pub/GNU/LilyPond/v1.3/
For more information about GNU LilyPond, please visit:
http://www.cs.uu.nl/~hanwen/lilypond/
# postinst script for the Debian GNU/Linux lilypond package
# by Anthony Fok <foka@debian.org>
# Initial release: Sun, 26 Oct 1997 03:23:00 -0700
-# Last modified: Sun, 26 Mar 2000 02:18:41 -0700
+# Last modified: Thu, 26 Apr 2001 03:20:10 -0600
set -e
echo " Running /usr/bin/mktexlsr $TEXMFMAIN..."
/usr/bin/mktexlsr $TEXMFMAIN
-install-info --description='LilyPond, the GNU Project music typesetter' \
+install-info --quiet \
--section "Music" "Music" \
- --quiet /usr/share/info/lilypond.info.gz
+ --description='LilyPond, the GNU Project music typesetter' \
+ /usr/share/info/lilypond.info.gz
#DEBHELPER#
echo
echo " $pkg_name configuration completed."
-echo " Please read /usr/share/doc/lilypond1.3/README.Debian to get started."
+echo " Please read /usr/share/doc/lilypond/README.Debian to get started."
# Currently maintained by Anthony Fok <foka@debian.org>
# for Debian GNU/Linux.
-package = lilypond1.3
+package = lilypond
SHELL = /bin/sh
r = debian/$(package)
-TMP = `pwd`/$(r)
+TMP = $(PWD)/$(r)
d = usr/share/doc/$(package)
+TELY_FILES := $(notdir $(wildcard Documentation/user/*.tely))
+DVI_FILES = $(addprefix Documentation/user/out/, $(TELY_FILES:.tely=.dvi))
+PS_FILES = $(DVI_FILES:.dvi=.ps)
+export MODE=ljfour
+export BDPI=600
+
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
# This is the debhelper compatibility version to use.
-export DH_COMPAT=2
+export DH_COMPAT=3
+
+# This has to be exported to make some magic below work.
+export DH_OPTIONS
build: build-stamp
build-stamp:
--enable-shared \
--infodir='$${prefix}/share/info' \
--mandir='$${prefix}/share/man'
- $(MAKE) all
- $(MAKE) -C Documentation
- $(MAKE) -C Documentation/user ps
+ $(MAKE) USER_CFLAGS=-DDEBIAN all
+ $(MAKE) -C Documentation/user dvi ps
$(MAKE) -C Documentation/pictures pngs
touch build-stamp
find . -user root | xargs -r chown --dereference $$SUDO_USER.$$SUDO_GID; \
fi
+install: DH_OPTIONS=
install: build
dh_testdir
dh_testroot
usr/share/texmf/fonts/tfm/public
ln -fs ../$(package) $(r)/usr/share/doc/texmf/lilypond
- $(MAKE) prefix=$(TMP)/usr install
+ $(MAKE) prefix=$(TMP)/usr USER_CFLAGS=-DDEBIAN install
ln -s ../../lilypond/tex $(r)/usr/share/texmf/tex/lilypond
ln -s ../../../../lilypond/mf $(r)/usr/share/texmf/fonts/source/public/lilypond
fi
# Build architecture-independent files here.
+binary-indep: DH_OPTIONS=-i
binary-indep: build install
-# We have nothing to do by default.
+ dh_testdir
+ dh_testroot
+ dh_installdocs
+ dh_installchangelogs
+ dh_link
+ dh_compress
+ dh_fixperms
+ dh_installdeb
+ dh_gencontrol
+ dh_md5sums
+ dh_builddeb
+binary-arch: DH_OPTIONS=-a
binary-arch: build install
- dh_testversion 2
dh_testdir
dh_testroot
cp -av lilypond-mode.el lilypond-font-lock.el \
dh_installdocs DEDICATION NEWS ROADMAP *.txt \
Documentation/pictures/out/*.png \
Documentation/out/*.txt \
- Documentation/*/out/[a-z]*.dvi \
- Documentation/*/out/*.ps
+ $(DVI_FILES) $(PS_FILES)
mkdir $(r)/$(d)/bibliography $(r)/$(d)/misc
cp -a Documentation/bibliography/*.bib $(r)/$(d)/bibliography/
cp -a Documentation/misc/[ACN]* $(r)/$(d)/misc/
dh_strip
dh_compress
dh_fixperms
-# dh_suidregister
dh_installdeb
dh_shlibdeps
dh_gencontrol
--- /dev/null
+
+\header {
+texidoc = "Stems are extended if flags and dots collide."
+}
+
+\score{
+ \notes\relative c'{ f8. g f16. g f32. g}
+}
+
"
}
-
-\include "paper23.ly"
-
\score { \notes \relative c''{
% \property Voice.Stem \override #'thickness = #5.0
\property Voice.NoteHead \set #'style = #'default
--- /dev/null
+\header {
+
+texidoc = "In combination with a beam, the bracket of the tuplet
+bracket is removed. This only happens if there is one beam, as long as
+the bracket."
+
+}
+
+\score { \notes \context Voice\relative c'' {
+\times 2/3 { r [c8 c8] }
+\times 2/3 { [c8 c c] }
+\times 2/3 { [c16 c16] [c8 c8] }
+}}
--- /dev/null
+\header {
+
+texidoc = "Horizontal tuplet brackets are shifted vertically
+to avoid staff line collisions."
+
+}
+
+\score { \notes \context Voice\relative c'' {
+\times 2/3 { b'4 b b }
+\times 2/3 { f4 f f }
+\times 2/3 { g4 g g }
+\times 2/3 { a4 a a }
+}}
clarinetti = \notes \relative c' {
\property Staff.midiInstrument = #"clarinet"
- \property Staff.instrument = #"2 Clarinetti\n(B\\textflat)"
- \property Staff.instr = #"Cl.\n(B\\textflat)"
+ \property Staff.instrument = #`(lines "2 Clarinetti" (columns "(B" (music "accidentals--1") ")"))
+ \property Staff.instr = #`(lines "Cl."(columns "(B" (music "accidentals--1") ")"))
R1*2 c1 R1*8
}
\property Staff.instrument = #"2 Fagotti"
\property Staff.instr = #"Fg."
+ \clef bass
R1*3 c1 R1*7
}
corni = \notes \relative c' {
\property Staff.midiInstrument = #"french horn"
- \property Staff.instrument = #"2 Corni\n(E\\textflat)"
- \property Staff.instr = #"Cor.\n(E\\textflat)"
+ \property Staff.instrument = #`(lines "2 Corni" (columns "(E" (music "accidentals--1") ")"))
+ \property Staff.instr = #`(lines "Cor." (columns "(E" (music "accidentals--1") ")"))
R1*4 c1 R1*6
}
trombe = \notes \relative c' {
\property Staff.midiInstrument = #"trumpet"
- \property Staff.instrument = #"2 Trombe\n(C)"
- \property Staff.instr = #"Tbe.\n(C)"
+ \property Staff.instrument = #'(lines "2 Trombe" "(C)")
+ \property Staff.instr = #'(lines "Tbe." "(C)")
+ \clef bass
R1*5 c1 R1*5
}
timpani = \notes \relative c' {
\property Staff.midiInstrument = #"timpani"
- \property Staff.instrument = #"Timpani\n(C-G)"
+ \property Staff.instrument = #'(lines "Timpani" "(C-G)")
\property Staff.instr = #"Timp."
R1*6 c1 R1*4
violinoI = \notes \relative c' {
\property Staff.midiInstrument = #"violin"
- \property Staff.instrument = #"Violino I"
- \property Staff.instr = #"Vl. I"
+ \property Staff.instrument = #"Violino I "
+ \property Staff.instr = #"Vl. I "
R1*7 c1 R1*3
}
violinoII = \notes \relative c' {
\property Staff.midiInstrument = #"violin"
- \property Staff.instrument = #"Violino II"
- \property Staff.instr = #"Vl. II"
+ \property Staff.instrument = #"Violino II "
+ \property Staff.instr = #"Vl. II "
R1*8 c1 R1*2
}
\property Staff.instrument = #"Viola"
\property Staff.instr = #"Vla."
+ \clef alto
R1*9 c1 R1*1
}
violoncello = \notes \relative c' {
\property Staff.midiInstrument = #"cello"
%\property Staff.midiInstrument = #"contrabass"
- \property Staff.instrument = #"Violoncello\ne\nContrabasso"
- \property Staff.instr = #"Vc.\nCb."
+ \property Staff.instrument = #'(lines "Violoncello" "e" "Contrabasso")
+ \property Staff.instr = #'(lines "Vc." "Cb.")
+ \clef bass
R1*10 c1
}
\context Voice = corII { \stemDown \M }
>
\context Staff = trp <
- \property Staff.instrument = "2 Trp. in B\\textflat "
+ \property Staff.instrument = #`(columns "2 Trp. in B " (music "accidentals--1"))
\property Staff.instr = "Trp."
\context Voice = trpI { \stemUp \M }
\context Voice = trpII { \stemDown \M }
\version "1.3.138"
-\header { title = "Two miniatures" }
+\header {
+ title = "Two miniatures"
+ tagline = "Small is beatiful"
+}
#(set! point-and-click line-column-location)
\lyrics \context Lyrics \text
>
\header{
- piece = "clarinet in B\\textflat"
+ piece = "clarinet in B$\flat$"
}
\paper { }
}
/*
TODO: make callback of this.
+
+ TODO:
+
+ note-width is hardcoded, making it difficult to handle all note
+ heads sanely. We should really look at the widths of the colliding
+ columns, and have a separate setting for "align stems".
+
+
*/
void
Collision::do_shifts (Grob* me)
SCM hand (forced_shift (me));
Link_array<Grob> done;
-
+
+
Real wid
= gh_scm2double (me->get_grob_property ("note-width"));
*/
#ifndef __CYGWIN__ /* mktextfm/mktexpk does not work on windows */
+#ifndef DEBIAN
unsetenv ("TFMFONTS");
+#endif
#endif
/*
kpse_set_program_name (av0, NULL);
kpse_maketex_option ("tfm", TRUE);
+#ifdef DEBIAN
+ String my_tfm = "$VARTEXFONTS/tfm/public/lilypond";
+#else
String my_tfm = "$VARTEXFONTS/tfm/lilypond/";
my_tfm += version_str () + "/";
+#endif
- char * mypath = kpse_expand (my_tfm.ch_C ());
+ char * mypath = kpse_expand ((my_tfm + ":").ch_C ());
+#ifndef DEBIAN
String prog = "mktextfm --destdir ";
prog += mypath;
kpse_format_info[kpse_tfm_format].program = strdup (prog.ch_C ());
+#endif
kpse_format_info[kpse_tfm_format].client_path = mypath;
#endif
}
&& (get_direction (me) != get_default_dir (me)))
length_f -= shorten_f;
+ Interval hp = head_positions (me);
+ Real st = hp[dir] + dir * length_f;
+
+ /*
+ Make a little room if we have a flag and there is a dot.
+
+ TODO:
+
+ maybe we should consider moving the dot to the right?
+ */
+
+ if (!beam_l (me)
+ && flag_i (me))
+ {
+ Grob * closest_to_flag = extremal_heads (me)[dir];
+ Grob * dots = closest_to_flag
+ ? Rhythmic_head::dots_l (closest_to_flag ) : 0;
- Real st = head_positions (me)[dir] + dir * length_f;
+ if (dots)
+ {
+ Real dp = Staff_symbol_referencer::position_f (dots);
+ Real flagy = flag (me).extent (Y_AXIS)[-dir] * 2; // should divide by staffspace
+
+ if (dir * (st + flagy - dp) < 0)
+ st += (fabs (st + flagy - dp) + 1.0) *dir;
+ }
+ }
bool no_extend_b = to_boolean (me->get_grob_property ("no-stem-extend"));
if (!grace_b && !no_extend_b && dir * st < 0) // junkme?
y_attach = head_height.linear_combination (y_attach);
stem_y[Direction (-d)] += d * 2*y_attach;
}
-
if (!invisible_b (me))
{
(c) 1997--2001 Jan Nieuwenhuizen <janneke@gnu.org>
*/
+#include <math.h>
#include "beam.hh"
#include "box.hh"
#include "group-interface.hh"
#include "directional-element-interface.hh"
#include "spanner.hh"
+#include "staff-symbol-referencer.hh"
/*
TODO:
{
Grob *me= unsmob_grob (smob);
Molecule mol;
+ Link_array<Grob> column_arr=
+ Pointer_group_interface__extract_elements (me, (Grob*)0, "columns");
+
+
+ if (!column_arr.size ())
+ return mol.smobbed_copy ();
+
+
+ Grob *b1 = Note_column::stem_l (column_arr[0]);
+ Grob *b2 = Note_column::stem_l (column_arr.top());
+
+ b1 = b1 ? Stem::beam_l (b1) : 0;
+ b2 = b2 ? Stem::beam_l (b2) : 0;
+
+
+ Spanner*sp = dynamic_cast<Spanner*> (me);
// Default behaviour: number always, bracket when no beam!
- bool par_beam = to_boolean (me->get_grob_property ("parallel-beam"));
+ bool par_beam = b1 && (b1 == b2) && !sp->broken_b() ;
+
bool bracket_visibility = !par_beam;
bool number_visibility = true;
else if (bracket == ly_symbol2scm ("if-no-beam"))
number_visibility = !par_beam;
- if (gh_pair_p (me->get_grob_property ("columns")))
- {
- Link_array<Grob> column_arr=
- Pointer_group_interface__extract_elements (me, (Grob*)0, "columns");
- Real ncw = column_arr.top ()->extent (column_arr.top (), X_AXIS).length ();
- Real w = dynamic_cast<Spanner*> (me)->spanner_length () + ncw;
-
- Real staff_space = 1.0;
- Direction dir = Directional_element_interface::get (me);
- Real dy = gh_scm2double (me->get_grob_property ("delta-y"));
- SCM number = me->get_grob_property ("text");
- if (gh_string_p (number) && number_visibility)
- {
- SCM properties = Font_interface::font_alist_chain (me);
- Molecule num = Text_item::text2molecule (me, number, properties);
- num.align_to (X_AXIS, CENTER);
- num.translate_axis (w/2, X_AXIS);
- num.align_to (Y_AXIS, CENTER);
- num.translate_axis (dir * staff_space, Y_AXIS);
+ Real ncw = column_arr.top ()->extent (column_arr.top (), X_AXIS).length ();
+ Real w = sp->spanner_length () + ncw;
+
+ Direction dir = Directional_element_interface::get (me);
+ Real dy = gh_scm2double (me->get_grob_property ("delta-y"));
+ SCM number = me->get_grob_property ("text");
+ if (gh_string_p (number) && number_visibility)
+ {
+ SCM properties = Font_interface::font_alist_chain (me);
+ Molecule num = Text_item::text2molecule (me, number, properties);
+ num.align_to (X_AXIS, CENTER);
+ num.translate_axis (w/2, X_AXIS);
+ num.align_to (Y_AXIS, CENTER);
- num.translate_axis (dy/2, Y_AXIS);
+ num.translate_axis (dy/2, Y_AXIS);
- mol.add_molecule (num);
- }
+ mol.add_molecule (num);
+ }
- if (bracket_visibility)
- {
- Real lt = me->paper_l ()->get_var ("stafflinethickness");
+ if (bracket_visibility)
+ {
+ Real lt = me->paper_l ()->get_var ("stafflinethickness");
- SCM thick = me->get_grob_property ("thick");
- SCM gap = me->get_grob_property ("number-gap");
+ SCM thick = me->get_grob_property ("thick");
+ SCM gap = me->get_grob_property ("number-gap");
- SCM at =gh_list (ly_symbol2scm ("tuplet"),
- gh_double2scm (1.0),
- gap,
- gh_double2scm (w),
- gh_double2scm (dy),
- gh_double2scm (gh_scm2double (thick)* lt),
- gh_int2scm (dir),
- SCM_UNDEFINED);
-
- Box b;
- mol.add_molecule (Molecule (b, at));
- }
+ SCM at =gh_list (ly_symbol2scm ("tuplet"),
+ gh_double2scm (1.0),
+ gap,
+ gh_double2scm (w),
+ gh_double2scm (dy),
+ gh_double2scm (gh_scm2double (thick)* lt),
+ gh_int2scm (dir),
+ SCM_UNDEFINED);
+
+ Box b;
+ mol.add_molecule (Molecule (b, at));
}
+
return mol.smobbed_copy ();
}
if (notey * d > (*offset + tuplety) * d)
*offset = notey - tuplety;
}
+
+ // padding
+ *offset += 1.0 *d;
+
+
+ /*
+ horizontal brackets should not collide with staff lines.
+
+
+ */
+ if (*dy == 0)
+ {
+ // quantize, then do collision check.
+ Real ss= Staff_symbol_referencer::staff_space (me);
+ *offset *= 2 / ss;
+
+ *offset = rint (*offset);
+ if (Staff_symbol_referencer::on_staffline (me, (int) rint (*offset)))
+ *offset += d;
+
+ *offset *= 0.5 * ss;
+ }
+
}
/*
Grob * me = unsmob_grob (smob);
Link_array<Note_column> column_arr=
Pointer_group_interface__extract_elements (me, (Note_column*)0, "columns");
- Spanner *sp = dynamic_cast<Spanner*> (me);
-
if (!column_arr.size ())
{
me->set_grob_property ("delta-y", gh_double2scm (dy));
me->translate_axis (offset, Y_AXIS);
-
- if (scm_ilength (me->get_grob_property ("beams")) == 1)
- {
- SCM bs = me->get_grob_property ("beams");
- Grob *b = unsmob_grob (gh_car (bs));
- Spanner * beam_l = dynamic_cast<Spanner *> (b);
- if (!sp->broken_b ()
- && sp->get_bound (LEFT)->column_l () == beam_l->get_bound (LEFT)->column_l ()
- && sp->get_bound (RIGHT)->column_l () == beam_l->get_bound (RIGHT)->column_l ())
- me->set_grob_property ("parallel-beam", SCM_BOOL_T);
- }
return SCM_UNSPECIFIED;
}
return d;
}
-void
-Tuplet_bracket::add_beam (Grob*me, Grob *b)
-{
- me->add_dependency (b);
- Pointer_group_interface::add_element (me, "beams",b);
-}
-
void
Tuplet_bracket::add_column (Grob*me, Item*n)
{
if (started_span_p_arr_[j])
Tuplet_bracket::add_column (started_span_p_arr_[j], dynamic_cast<Item*> (i.elem_l_));
}
- else if (Beam::has_interface (i.elem_l_))
- {
- /*
- TODO:
-
- ugh, superfluous. Should look at
-
- tuplet -> note-column -> stem -> beam
-
- to find the beam(s) of a tuplet
- */
-
- for (int j = 0; j < started_span_p_arr_.size (); j++)
- if (started_span_p_arr_[j])
- Tuplet_bracket::add_beam (started_span_p_arr_[j],i.elem_l_);
- }
}
void
--- /dev/null
+;; install this into emacs site-start.d/
+
+(autoload 'LilyPond-mode "lilypond-mode")
+(setq auto-mode-alist
+ (cons '("\\.ly$" . LilyPond-mode) auto-mode-alist))
+
+(add-hook 'LilyPond-mode-hook (lambda () (turn-on-font-lock)))
+
+
+
+
% 16' = S
%
-#(eval-string (ly-gulp-file "accordion-script.scm"))
-
accDiscant = \script "accDiscant"
accDiscantF = \script "accDiscantF"
accDiscantE = \script "accDiscantE"
% 2001/03/25 Rune Zedeler <rune@zedeler.dk>
+%% TODO: don't pollute global namespace in this way .
+
+
#(define drum-pitch-names `(
(acousticbassdrum bda ,(make-pitch -3 6 0 ))
(bassdrum bd ,(make-pitch -2 0 0 ))
(mutehiconga cghm ,(make-pitch 0 1 0))
(openhiconga cgho ,(make-pitch 0 1 1))
(hiconga cgh ,(make-pitch 0 2 -1))
+ (openloconga cglo ,(make-pitch 0 1 2))
(loconga cgl ,(make-pitch 0 2 0))
(hitimbale timh ,(make-pitch 0 3 0))
(lotimbale timl ,(make-pitch 0 3 1))
#(define congas `(
(losidestick cross ,#f ,(make-pitch -1 6 0))
(loconga default ,#f ,(make-pitch -1 6 0))
+ (openloconga default ,"open" ,(make-pitch -1 6 0))
(hisidestick cross ,#f ,(make-pitch 0 1 0))
(hiconga default ,#f ,(make-pitch 0 1 0))
- (openhiconga default open" ,(make-pitch 0 1 0))
- (mutehiconga default stopped" ,(make-pitch 0 1 0))
+ (openhiconga default "open" ,(make-pitch 0 1 0))
+ (mutehiconga default "stopped" ,(make-pitch 0 1 0))
+
))
#(define bongos `(
Begin3
Title: LilyPond
-Version: 1.3.152
-Entered-date: 04MAY01
+Version: 1.3.153
+Entered-date: 08MAY01
Description: @BLURB@
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.3.152.tar.gz
+ 1000k lilypond-1.3.153.tar.gz
Original-site: ftp.cs.uu.nl /pub/GNU/LilyPond/development/
- 1000k lilypond-1.3.152.tar.gz
+ 1000k lilypond-1.3.153.tar.gz
Copying-policy: GPL
End
%define info yes
Name: lilypond
-Version: 1.3.152
+Version: 1.3.153
Release: 1
License: GPL
Group: Applications/Publishing
-Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.3.152.tar.gz
+Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.3.153.tar.gz
Summary: Create and print music notation
URL: http://www.cs.uu.nl/~hanwen/lilypond
BuildRoot: /tmp/lilypond-install
%files
-%{_datadir}/emacs/site-lisp/*
-%{_datadir}/emacs/site-lisp/site-start.d/*
+%{_datadir}/emacs/site-lisp/lilypond-*
+%{_datadir}/emacs/site-lisp/site-start.d/lilypond-*
%{_prefix}/bin/abc2ly
%{_prefix}/bin/as2text
Distribution: SuSE Linux 7.0 (i386)
Name: lilypond
-Version: 1.3.152
+Version: 1.3.153
Release: 2
Copyright: GPL
Group: Applications/Publishing
-Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.3.152.tar.gz
+Source0: ftp.cs.uu.nl:/pub/GNU/LilyPond/development/lilypond-1.3.153.tar.gz
# music notation software for.. ?
Summary: A program for printing sheet music.
URL: http://www.lilypond.org/
%files
-%{_datadir}/emacs/site-lisp/*
-%{_datadir}/emacs/site-lisp/site-start.d/*
+%{_datadir}/emacs/site-lisp/lilypond-*
+%{_datadir}/emacs/site-lisp/site-start.d/lilypond-*
%{_prefix}/bin/abc2ly
%{_prefix}/bin/as2text
input feta-accordion;
input feta-custodes;
else:
-% input feta-bolletjes;
-% input feta-banier;
+ input feta-bolletjes;
+ input feta-banier;
% input feta-eindelijk;
% input feta-klef;
% input feta-toevallig;
% input feta-schrift;
% input feta-haak;
- input feta-timesig;
+ %input feta-timesig;
% input feta-pendaal;
% input feta-accordion;
fi
--- /dev/null
+% Gray font for LJ with proofsheet resolution 150 pixels per inch.
+% Each pixel is represented by a 4x4 square, with 4/16 of the dots on.
+
+
+font_identifier "GRAYLJ";
+
+boolean lightweight;
+
+input grayf
+++ /dev/null
---- mktexnam.orig Sun Mar 4 19:29:45 2001
-+++ mktexnam Tue May 8 20:28:57 2001
-@@ -158,6 +158,7 @@
- MT_PKDESTDIR=$DEST
- MT_TFMDESTDIR=$DEST
- MT_MFDESTDIR=$DEST
-+ MT_DESTROOT=foobar
- MT_NAMEPART=;;
- *) # Relative destdir => append to the default.
- MT_NAMEPART=$DEST;;
tuplet_dy tuplet_dx div tuplet_gapx mul /tuplet_gapy exch def
- 0 0 moveto
- 0 tuplet_h dir mul lineto
+ 0 tuplet_h neg dir mul moveto
+ 0 0 lineto
tuplet_dx tuplet_gapx sub 2 div
- tuplet_dy tuplet_gapy sub 2 div tuplet_h dir mul add lineto
+ tuplet_dy tuplet_gapy sub 2 div lineto
tuplet_dx tuplet_gapx add 2 div
- tuplet_dy tuplet_gapy add 2 div tuplet_h dir mul add moveto
- tuplet_dx tuplet_dy tuplet_h dir mul add lineto
+ tuplet_dy tuplet_gapy add 2 div moveto
tuplet_dx tuplet_dy lineto
+ tuplet_dx tuplet_dy tuplet_h dir neg mul add lineto
stroke
} bind def
(if (equal? "8" (substring cl (- l 1) l))
(begin
(if (equal? "^" (substring cl (- l 2) (- l 1)))
- (set! oct 7)
- (set! oct -7))
+ (set! oct -7)
+ (set! oct 7))
(set! cl (substring cl 0 (- l 2)))))
))
(NoteCollision . (
(axes 0 1)
- (note-width . 1.65)
+ ;; Ugh, should not be hard-coded.
+ (note-width . 1.321)
(meta . ,(grob-description "NoteCollision"
note-collision-interface axis-group-interface
))
'tuplet-bracket-interface
"A bracket with a number in the middle, used for tuplets."
'(
- beams
columns
number-gap
delta-y
tuplet-bracket-visibility
tuplet-number-visibility
- parallel-beam
thick
))
((baroque)
(string-append (number->string duration)
(if (< duration 0) "mensural" "")))
+ ((mensural) (string-append (number->string duration) (symbol->string style)))
((default) (number->string duration))
(else
(string-append (number->string (max 0 duration)) (symbol->string style)))))
local-distclean:
rm -f config.h config.hh config.make Makefile GNUmakefile \
config.cache config.status config.log index.html \
- afm tfm cmtfm share/locale/*/LC_MESSAGES/lilypond.mo
+ stepmake/stepmake/stepmake stepmake/stepmake/bin
local-maintainerclean:
rm -f configure
projects / lilypond.git / commitdiff