@end ignore
+@item
+Markup-commands @code{\undertie} and @code{\overtie} are now available, as well
+the generic markup-command @code{\tie}.
+@lilypond[quote,verbatim]
+\markup {
+ \undertie "undertied"
+ \overtie "overtied"
+}
+
+m = {
+ c''1 \prall -\tweak text \markup \tie "131" -1
+}
+
+{ \voiceOne \m \voiceTwo \m }
+@end lilypond
+
@item
@code{TabStaff} is now able to print micro-tones for bendings etc.
@lilypond[quote,verbatim]
\layout {
\context {
\Score
- noteToFretFunction = #(determine-frets #t)
+ supportNonIntegerFret = ##t
}
}
@node Meisters
@section Meisters
-We have four jobs for organizing a team of contributors:
+We have four primary jobs to help organize all our contributors:
+
+@unnumberedsubsec The Bug Meister
+
+The Bug Meister's responsibilities are:
+
+@itemize
+
+@item
+To organize the individual Bug Squad volunteers, making sure that
+each member is aware of their responsibilities. See
+@ref{The Bug Squad}.
+
+@item
+To train new Bug Squad volunteers in the Issue Tracker process. See
+@ref{Issues}.
+
+@item
+To have the final say on our policies for Issues and their
+classification. See @ref{Issue classification}.
+
+@end itemize
+
+Current Bug Meister: Colin Hall @email{bug-lilypond@@gnu.org}
+
+
+@unnumberedsubsec The Doc Meister
+
+The Doc Meister's responsibilities are:
+
+@itemize
+
+@item
+To train new volunteers in our Documentation style and policy,
+including organizing LilyPond Snippet Repository (LSR) work.
+
+@item
+To organize the individual volunteers -- who does what on which job --
+and to check that everything is running smoothly.
+
+@item
+To have final say on any Documentation policy. See
+@ref{Documentation policy}.
+
+@end itemize
+
+Current Doc Meister: None
+
+
+@unnumberedsubsec The Patch Meister
+
+The Patch Meister's responsibilities are:
@itemize
@item
-Bug Meister: trains new Bug Squad volunteers, organizes who works
-on which part of their job, checks to make sure that everything is
-running smoothly, and has final say on our policy for Issues.
+To keep track of all patches submitted for testing and review. This
+includes scanning the bug and dev email lists looking for any patches
+submitted by @q{random} contributors and advising them on how to submit
+a patch for testing and review. See @ref{Commits and patches}.
-Currently: Colin H
+@item
+To makes sure that any patch submitted has a corresponding Issue Tracker
+and Rietveld Issue created for it before it enters the testing and
+review process. See @ref{Issues}.
@item
-Doc Meister: trains new doc editors/writers, organizes who works
-on which part of the job, checks to make sure that everything is
-running smoothly, and has final say on our policy for
-Documentation. Also includes LSR work.
+Updates all Issue statuses for all patches that are currently in the
+testing and review process periodically -- currently every 3 - 4 days.
+See @ref{Patch handling}.
+
+@end itemize
-Currently: None
+@warning{The Patch Meister's role is a purely administrative one and no
+programming skill or judgement is assumed or required.}
+
+Currently: James Lowe @email{pkx@@gnu.org}
+
+
+@unnumberedsubsec The Translation Meister
+
+The Translation Meister's responsibilities are:
+
+@itemize
@item
-Translation Meister: trains new translators, updates the
-translation priority list, and handles merging branches (in both
-directions).
+To train new documentation translators in the translation process. See
+@ref{Translating the documentation}.
-Currently: Francisco
+@item
+To update the translation priority list and handle the merging of the
+translation branches (in both directions).
+
+@item
+To have final say on any Translation management policies. See
+@ref{Translating the documentation}.
@end itemize
+Currently: Francisco Vila @email{translations@@lilynet.net}
+
+
@node Managing Staging and Master branches with Patchy
@section Managing Staging and Master branches with Patchy
@enumerate
@item
-upload it with our custom @code{git-cl}. In addition to uploading
-it to the google rietveld code review tool, this adds a tracker
-issue so that we don't lose your patch. The @qq{status} of your
-patch is kept on the issue tracker; see @ref{Issues}.
+upload it with our custom @code{git-cl} @q{helper-script}; see
+@ref{git-cl}. In addition to uploading patches to the Google's Rietveld
+Code Review Tool the script will also update the issue tracker (or add a
+new issue as appropriate) so that we don't lose reference to your
+patch. The @qq{status} of your patch is kept on the issue tracker;
+see @ref{Issues}.
-@example
-@uref{https://github.com/gperciva/git-cl}
-@end example
-
-Your patch will be given @code{Patch-new} status. More info in
-@ref{Uploading a patch for review}.
+Your patch will be given @code{Patch-new} status. More information on
+this can be found in the section @ref{Uploading a patch for review}.
@item
If your patch passes some automatic tests, it will be given
@item
After that, the patch must wait for the next @qq{patch countdown},
-which occur 3 times a week. If there are a lot of patches waiting
-for a countdown, a subset of patches are chosen randomly. When
-your patch is put on a countdown, it will be given
-@code{Patch-countdown} status.
+which occurs roughly every 3 days. When your patch is put on a
+countdown, it will be given @code{Patch-countdown} status.
@item
-The countdown is a 48-hour period which gives other developers one
+The countdown is a 72-hour period which gives other developers one
last chance to review the patch. If no significant problems are
found, your patch will be given @code{Patch-push} status.
unintended breakage in @code{master}, this is the best compromise
we have found.}
-@c I don't think this is important enough to list here, but I may
-@c change my mind and/or leave a link to a later CG section.
-@ignore
-@item @strong{code style}:
-C++ code should be formatted with
-@file{scripts/auxiliar/fixcc.py}, which requires
-@url{http://astyle.sourceforge.net/, astyle 2.02}. However, we
-are not very strict about this requirement.
-
-At the moment, scheme code should be formatted @qq{like emacs does
-it}. We are working on an automated tool to simplify this step.
-However, we are not very strict about this requirement either.
-@end ignore
-
@end itemize
@menu
* LilyDev::
* lily-git::
+* git-cl::
* Compiling with LilyDev::
* Now start work!::
@end menu
@menu
* Where to get lily-git::
-* Configuring lily-git and downloading the source code::
+* Using lily-git to download the source code::
* How to use lily-git::
@end menu
@itemize
@item
-If you are using LilyDev (see @ref{LilyDev}) then lily-git should be
-already installed and ready to run. This is not the case for the
-current version (3.0), but you can easily turn it on by adding this
-line in ~/.bashrc:
+If you are using LilyDev (see @ref{LilyDev}) then lily-git should
+already be installed and ready to run. If this is not the case you can
+easily turn it on by adding the following line in @code{~/.bashrc}:
@example
# add lily-git to the PATH
@end example
@item
-For those not using LilyDev then lily-git can be obtained by downloading
+For those not using LilyDev, lily-git can be obtained by downloading
the software directly. See @ref{Manually installing lily-git.tcl}.
@item
-Finally, lily-git is always part of the LilyPond source code and is
-located in @file{$LILYPOND_GIT/scripts/auxillar/lily-git.tcl}.
+lily-git is part of the LilyPond source code and is located in
+@file{$LILYPOND_GIT/scripts/auxillar/lily-git.tcl}.
@end itemize
-@node Configuring lily-git and downloading the source code
-@unnumberedsubsec Configuring lily-git and downloading the source code
-
-@warning{The rest of this manual assumes that you are using the
-command-line within a terminal.}
+@node Using lily-git to download the source code
+@unnumberedsubsec Using lily-git to download the source code
@enumerate
@item
-Type (or copy&paste) into the Terminal:
+Type the following command into a Terminal:
@example
lily-git.tcl
@end example
@noindent
-You will be prompted to enter your name and your email address. This
-information is used only to identify and label any patches you create.
-This information can be edited if required later. See
-@ref{Configuring Git}. Click on the @emph{Submit} button to update
-lily-git with this information.
+You will be prompted to enter a name and email address into the lily-git
+UI. This information is used to label any patches you create (using the
+lily-git UI or git via the command line) and can be changed later if
+required. See @ref{Configuring Git}.
+
+@item
+Click on the @emph{Submit} button to update lily-git with the
+information.
@item
Click on the @qq{Get source} button.
-A directory called @file{$LILYPOND_GIT} is now created within
-your home directory and the complete source code will start to be
-downloaded into it.
+A directory called @file{lilypond-git} is created within your home
+directory and the entire source code will start to be downloaded into
+it.
-@warning{Be patient! The complete source is around 150@tie{}Mb.}
+@warning{Be patient! There is no progress bar in the lily-git UI but the
+complete source is around 180@tie{}Mb.}
@noindent
-When the source code has been downloaded, the @qq{Command output} window
-in lily-git will update and display @qq{Done} on the very last line.
-The button label will change to say @qq{Update source}.
+When the source code has been downloaded, the @qq{command output} window
+in the lily-git UI will update and display @qq{Done} on the very last
+line and the button label will change to say @qq{Update source}.
@warning{Some contributors have reported that occasionally nothing
happens at this step at all. If this occurs, then try again in a few
problem persists, please ask for help.}
@item
-Close the lily-git GUI and navigate to the @file{$LILYPOND_GIT}
+Close the lily-git GUI and navigate to the @file{lilypond-git}
directory to view and edit the source files.
@end enumerate
@noindent
-If this is the first time you have compiled LilyPond then please go
-to @ref{Compiling with LilyDev} before reading on.
+If this is the first time you will be attempting to compile LilyPond,
+please see the section @ref{Compiling with LilyDev} before continuing.
@node How to use lily-git
@unnumberedsubsec How to use lily-git
-@warning{Throughout the rest of this manual, most command-line
-input should be entered from @file{~/lilypond-git/}. This is
-known as the @emph{top source directory} and is often referred to as
-@var{$LILYPOND_GIT}.}
+Here is a brief description of what each button does in the lily-git UI.
-@warning{Only work on one set of changes at once. Do not start
-work on any new changes until your first set has been accepted.}
+@advanced{Throughout the rest of this manual, most command-line
+input should be entered from within the top level of the
+@file{~/lilypond-git/} directory. This is known as the
+@emph{top of the source directory} and is also referred to as
+@var{$LILYPOND_GIT} as a convention for those users who may have
+configured their own locations of the LilyPond source code.}
+
+@warning{For those less experienced contributors using lily-git, we
+recommend that you only work on one set of changes at a time and not
+start on any new changes until your first set has been accepted.}
@subsubheading 1. Update source
-At the beginning of each session of lilypond work, you should
-click the @qq{Update source} button to get the latest changes to
-the source code.
+Click the @qq{Update source} button to get any recent changes to the
+source code that have been added by other contributors since your last
+session.
-@warning{In some rare and unfortunate circumstances, this will
-result in a @emph{merge conflict}. If this occurs, follow the
-instructions for @qq{Abort changes}, below. Your work will not be
-lost.}
+@warning{If another contributor has updated files in the source code
+that you had been working on then updating your own copy of the source
+code may result in what is known as a @emph{merge conflict}. If this
+occurs, follow the instructions to @qq{Abort changes}, below. Note that
+your work will not be lost.}
@subsubheading 2a. New local commit
current state of the remote repository (at @code{git.sv.gnu.org}).
+@node git-cl
+@section git-cl
+
+@menu
+* Installing git-cl::
+* Updating git-cl::
+* Configuring git-cl::
+@end menu
+
+Git-cl is a @q{helper script} that uploads patches to Google's Rietveld
+Code Review Tool -- used by the developers for patch review -- and, at
+the same time, updates LilyPond's issue tracker.
+
+
+@node Installing git-cl
+@unnumberedsubsec Installing @code{git-cl}
+
+@warning{LilyDev users can jump straight to the next section on updating
+@command{git-cl} as it will already be installed in your home
+directory.}
+
+@enumerate
+
+@item
+Download @command{git-cl} by running the command:
+
+@example
+git clone https://github.com/gperciva/git-cl.git
+@end example
+
+@noindent
+or, if that command fails for any reason, try:
+
+@example
+git clone git://github.com/gperciva/git-cl.git
+@end example
+
+@item
+Add the @file{git-cl/} directory to your @var{PATH} or create a symbolic
+link to the @command{git-cl} and @command{upload.py} scripts in one of
+your @var{PATH} directories (e.g. @file{$HOME/bin}).
+
+In GNU/Linux you can add directories to @var{PATH} by adding this line
+to your @file{.bashrc} file located in your home directory:
+
+@example
+PATH=~/directory_containing_git-cl:"$@{PATH@}"
+@end example
+
+@end enumerate
+
+
+@node Updating git-cl
+@unnumberedsubsec Updating @code{git-cl}
+
+LilyDev users should always make sure that they alwsys have the latest
+version of git-cl installed. It is possible that changes may have been
+made to git-cl that are not (yet) included in the version of LilyDev has
+been installed.
+
+@noindent
+Using a terminal run the following commands:
+
+@example
+cd ~/git-cl/
+git pull
+@end example
+
+This will download and update you to the lastest version of git-cl.
+
+
+@node Configuring git-cl
+@unnumberedsubsec Configuring @code{git-cl}
+
+@subsubheading Set up login accounts
+
+Because the @code{git-cl} updates two separate websites (Google's
+Rietveld Code Review Tool and LilyPond's issue tracker) you @emph{must}
+have a valid user login and password to both sites.
+
+@noindent
+Although that it may appear that you have to use a @q{Google} email
+address for the Rietveld Code Review Tool when you sign up, you can
+instead select the option @qq{I prefer to use my current email address}
+during sign up.
+
+@noindent
+For a user login to the LilyPond issue tracker, please send your
+request, preferably using the email address you want to use for your
+login, to the LilyPond Developer's mailing list
+(@code{lilypond-devel@@gnu.org}).
+
+@subsubheading Authorising git-cl for the LilyPond issue tracker
+
+The @code{git-cl} command itself also needs to be @q{authorized} so that
+it can access the LilyPond issue tracker.
+
+@enumerate
+@item
+Once a valid login has been given for the LilyPond issye tracker, go to
+the @q{Account settings} and select the @q{OAuth} tab.
+
+@item
+Locate the @q{Register New Application} section and enter @code{git-cl}
+in the @q{Application Name:} field.
+
+@item
+Click on the @q{Register new application} button. You should now see
+@q{git-cl} listed under the @q{My Applications} section.
+
+@item
+Click on the @q{Generate Bearer Token} button. You should now see
+@q{git-cl} listed under the @q{Authorized Applications} section along
+with a value for the @q{Bearer Token} entry. This value is used, in the
+next steps, to allow git-cl to access and update the LilyPond issue
+tracker.
+
+@end enumerate
+
+@subsubheading Running git-cl for the first time
+
+@enumerate
+@item
+Using a terminal, move to top source directory of the
+@code{$LILYPOND_GIT} directory and then run @code{git-cl} with the
+@code{config} option:
+
+@example
+cd $LILYPOND_GIT
+git-cl config
+@end example
+
+@item
+When prompted for the @code{Rietveld server}:
+
+@example
+Rietveld server (host[:port]) [codereview.appspot.com]:
+@end example
+
+@item
+When prompted for the @code{Allura server} (the LilyPond issue tracker):
+
+@example
+Allura server [https://sourceforge.net/p/testlilyissues/issues/]:
+@end example
+
+@item
+When prompted for the @code{Allura bearer token} copy/paste the value
+generated in the previous steps for
+@emph{Authorising git-cl for the LilyPond issue tracker}:
+
+@smallexample
+Allura bearer token (see https://sourceforge.net/auth/oauth/) [fdbfca60801533465480]:
+@end smallexample
+
+@warning{The above is a @q{fake} bearer token just to illustrate the
+example. Do not use this value.}
+
+@item
+Finally, when prompted for the @code{CC list} entry, add the Lilypond
+Developer's group email.
+
+@example
+CC list ("x" to clear) [lilypond-devel@@gnu.org]:
+@end example
+
+@end enumerate
+
+The @code{git-cl} script should now be correctly configured for use.
+
@node Compiling with LilyDev
@section Compiling with LilyDev
@subsubheading Uploading patch set
+This section assumes that you have already configured the
+@command{git-cl} @q{helper-script}. See @ref{git-cl}.
+
@warning{Unless you are familiar with branches, only work on one
set of changes at once.}
@example
git pull -r
-git cl upload origin/master
+git-cl upload origin/master
@end example
@c Mention staging here?
Un @code{TabStaff} peut contenir des micro-intervalles tels les quarts
de ton, qui interveiennent dans les chutes ou sauts. L'assertion
-@w{@code{noteToFretFunction = #(determine-frets #t)}} devra se placer au
+@w{@code{supportNonIntegerFret = ##t}} devra se placer au
niveau du contexte @code{Score}. Les micro-intervalles ne sont
toutefois pas pris en charge dans un contexte @code{FretBoards}.
\layout {
\context {
\Score
- noteToFretFunction = #(determine-frets #t)
+ supportNonIntegerFret = ##t
}
}
@code{TabStaff} may support micro-tones like quarter-tones, which
can be played using bendings.
-@code{noteToFretFunction = #(determine-frets #t)} needs to be set in
+@code{supportNonIntegerFret = ##t} needs to be set in
Score-context. However, micro-tones are not supported in @code{FretBoards}.
@lilypond[quote,ragged-right,verbatim]
\layout {
\context {
\Score
- noteToFretFunction = #(determine-frets #t)
+ supportNonIntegerFret = ##t
}
}
\header {
title = "DAS WOHLTEMPERIRTE CLAVIER"
subtitle = "TEIL I"
- % Do not display the tagline for this book
+ % Do not display the default LilyPond footer for this book
tagline = ##f
}
\markup { \vspace #1 }
meter = "Meter"
arranger = "Arranger"
% The following fields are centered at the bottom
- tagline = "tagline goes at the bottom of the last page"
- copyright = "copyright goes at the bottom of the first page"
+ tagline = "The tagline goes at the bottom of the last page"
+ copyright = "The copyright goes at the bottom of the first page"
}
\score {
{ s1 }
@end itemize
-The default tagline can be changed by adding a @code{tagline} in the
-top-level @code{\header} block.
+The default LilyPond footer text can be changed by adding a
+@code{tagline} in the top-level @code{\header} block.
@lilypond[papersize=a8landscape,verbatim]
\book {
}
@end lilypond
-To remove the @code{tagline} set the value to @code{##f}.
+To remove the default LilyPond footer text, the @code{tagline} can be
+set to @code{##f}.
@node Custom titles headers and footers
@node Table of contents
@subsection Table of contents
-A table of contents is included using the @code{\markuplist \table-of-contents}
-command. The elements which should appear in the table of contents are
-entered with the @code{\tocItem} command, which may be used either at
-top-level, or inside a music expression.
+A table of contents is included using the
+@code{\markuplist \table-of-contents} command. The elements which
+should appear in the table of contents are entered with the
+@code{\tocItem} command, which may be used either at top-level, or
+inside a music expression.
@verbatim
\markuplist \table-of-contents
}
@end verbatim
-The markups which are used to format the table of contents are defined
-in the @code{\paper} block. The default ones are @code{tocTitleMarkup},
-for formatting the title of the table, and @code{tocItemMarkup}, for
-formatting the toc elements, composed of the element title and page
-number. These variables may be changed by the user:
+Markups used for formatting the table of contents are defined in the
+@code{\paper} block. There two @q{pre-defined} markups already
+available;
+
+@itemize
+
+@item
+@code{tocTitleMarkup}
+
+@noindent
+Used for formatting the title of the table of contents.
+
+@verbatim
+tocTitleMarkup = \markup \huge \column {
+ \fill-line { \null "Table of Contents" \null }
+ \null
+}
+@end verbatim
+
+@item
+@code{tocItemMarkup}
+
+@noindent
+Used for formatting the elements within the table of contents.
+
+@verbatim
+tocItemMarkup = \markup \fill-line {
+ \fromproperty #'toc:text \fromproperty #'toc:page
+}
+@end verbatim
+
+@end itemize
+
+@noindent
+Both of these variables can be changed.
+
+Here is an example changing the table of contents' title into French;
@verbatim
\paper {
- %% Translate the toc title into French:
tocTitleMarkup = \markup \huge \column {
\fill-line { \null "Table des matières" \null }
\hspace #1
}
- %% use larger font size
- tocItemMarkup = \markup \large \fill-line {
- \fromproperty #'toc:text \fromproperty #'toc:page
- }
+@end verbatim
+
+Here is an example changing the font-size of the elements in the table
+of contents;
+
+@verbatim
+tocItemMarkup = \markup \large \fill-line {
+ \fromproperty #'toc:text \fromproperty #'toc:page
}
@end verbatim
-Note how the toc element text and page number are referred to in
-the @code{tocItemMarkup} definition.
+Note how the element text and page numbers are referred to in the
+@code{tocItemMarkup} definition.
-New commands and markups may also be defined to build more elaborated
-table of contents:
-@itemize
-@item first, define a new markup variable in the @code{\paper} block
-@item then, define a music function which aims at adding a toc element
-using this markup paper variable.
-@end itemize
+The @code{\tocItemWithDotsMarkup} command can be included within the
+@code{tocItemMarkup} to fill the line, between a table of contents item
+and its corresponding page number, with dots;
+
+@lilypond[verbatim,line-width=10.0\cm]
+\header { tagline = ##f }
+\paper {
+ tocItemMarkup = \tocItemWithDotsMarkup
+}
+
+\book {
+ \markuplist \table-of-contents
+ \tocItem \markup { Allegro }
+ \tocItem \markup { Largo }
+ \markup \null
+}
+@end lilypond
-In the following example, a new style is defined for entering act names
-in the table of contents of an opera:
+Custom commands with their own markups can also be defined to build a
+more complex table of contents. In the following example, a new style
+is defined for entering act names in a table of contents of an opera;
+
+@noindent
+A new markup variable (called @code{tocActMarkup}) is defined in the
+@code{\paper} block ;
@verbatim
\paper {
\hspace #1
}
}
+@end verbatim
+
+@noindent
+A custom music function (@code{tocAct}) is then created -- which uses
+the new @code{tocActMarkup} markup definition.
+@verbatim
tocAct =
-#(define-music-function (text) (markup?)
- (add-toc-item! 'tocActMarkup text))
+ #(define-music-function (text) (markup?)
+ (add-toc-item! 'tocActMarkup text))
@end verbatim
+@noindent
+A LilyPond input file, using these customer definitions, could look
+something like this;
+
@lilypond[line-width=10.0\cm]
\header { tagline = ##f }
\paper {
}
@end lilypond
-Dots can be added to fill the line between an item and its page number:
-@lilypond[verbatim,line-width=10.0\cm]
-\header { tagline = ##f }
-\paper {
- tocItemMarkup = \tocItemWithDotsMarkup
-}
+Here is an example of the @code{\fill-with-pattern} command used within
+the context of a table of contents;
-\book {
- \markuplist \table-of-contents
- \tocItem \markup { Allegro }
- \tocItem \markup { Largo }
- \markup \null
+@verbatim
+\paper {
+ tocItemMarkup = \markup { \fill-line {
+ \override #'(line-width . 70)
+ \fill-with-pattern #1.5 #CENTER . \fromproperty #'toc:text \fromproperty #'toc:page
+ }
+ }
}
-@end lilypond
+@end verbatim
@seealso
Installed Files:
@cindex repeat with pickup
@cindex pickup in a repeat
@funindex \partial
-
-If a repeat starts in the middle of a measure and has no alternate
-endings, normally the end of the repeat will also fall in the
-middle of a measure, so that the two ends add up to one complete
-measure. In such cases, the repeat signs do not constitute true
-bar lines. Do not use @code{\partial} commands or bar checks
-where these repeat signs are printed:
-
-@lilypond[verbatim,quote]
-\relative { % no \partial here
- c'4 e g % no bar check here
- % no \partial here
- \repeat volta 4 {
- e4 |
- c2 e |
- % no \partial here
- g4 g g % no bar check here
- }
- % no \partial here
+@cindex bar checks with repeats
+@cindex repeats with bar checks
+
+If a repeat that has no alternate endings starts in the middle of a
+measure, it will usually end at a corresponding place in the middle of a
+later measure (so that the two ends add up to one complete measure). In
+this case the repeat signs are not @q{true} bar lines so neither bar
+checks nor @code{\partial} commands should be placed there:
+
+@lilypond[verbatim,quote,relative=1]
+c'4 e g
+\repeat volta 4 {
+ e4 |
+ c2 e |
+ g4 g g
+}
g4 |
a2 a |
g1 |
-}
@end lilypond
-Similarly, if a repeat begins with the initial partial measure of
-a score and has no alternate endings, the same conditions apply as
-in the above example, except that in this case the @code{\partial}
-command is required at the beginning of the score:
+If a repeat that has no alternate endings starts with a partial measure,
+then the same principles apply, except that a @code{\partial} command is
+required at the start of the measure:
-@lilypond[verbatim,quote]
-\relative {
- \partial 4 % required
- \repeat volta 4 {
- e'4 |
- c2 e |
- % no \partial here
- g4 g g % no bar check here
- }
- % no \partial here
+@lilypond[verbatim,quote,relative=1]
+\partial 4
+\repeat volta 4 {
+ e'4 |
+ c2 e |
+ g4 g g
+}
g4 |
a2 a |
g1 |
-}
@end lilypond
@cindex repeats, with ties
@c used for news about the upcoming release; see CG 10.2
@newsItem
-@subheading LilyPond 2.19.31 released @emph{November 8, 2015}
+@subheading LilyPond 2.19.32 released @emph{November 22, 2015}
We are happy to announce the release of LilyPond
-2.19.31. This release includes a number of enhancements, and contains some
+2.19.32. This release includes a number of enhancements, and contains some
work in progress. You will have access to the very latest features, but
some may be incomplete, and you may encounter bugs and crashes. If you
require a stable version of Lilypond, we recommend using the 2.18
* don't duplicate entries from news-front.itexi
@end ignore
+@newsItem
+@subheading LilyPond 2.19.31 released @emph{November 8, 2015}
+
+We are happy to announce the release of LilyPond
+2.19.31. This release includes a number of enhancements, and contains some
+work in progress. You will have access to the very latest features, but
+some may be incomplete, and you may encounter bugs and crashes. If you
+require a stable version of Lilypond, we recommend using the 2.18
+version.
+
+@newsEnd
+
@newsItem
@subheading LilyPond 2.19.30 released @emph{October 25, 2015}
PACKAGE_NAME=LilyPond
MAJOR_VERSION=2
MINOR_VERSION=19
-PATCH_LEVEL=32
+PATCH_LEVEL=33
MY_PATCH_LEVEL=
VERSION_STABLE=2.18.2
-VERSION_DEVEL=2.19.31
+VERSION_DEVEL=2.19.32
--- /dev/null
+\version "2.19.32"
+
+\header {
+
+ doctitle = "Beam subdivide over quarter notes"
+
+ texidoc = "Beam subdivisions should match the durations of the subdivided
+groups, as established by baseMoment. However, if the groups are equal or
+longer than quarter notes, one beam should be left
+"
+
+}
+
+\relative c' {
+ \set baseMoment = #(ly:make-moment 1/4)
+ \set subdivideBeams = ##t
+ c16 [ c c c c c c c c c c c c c c c ]
+}
\header {
texidoc = "The @code{TabStaff} will print micro-tones as mixed numbers of
fret-number and a fraction.
-@code{noteToFretFunction = #(my-determine-frets #t)} needs to be set in Score.
+The context-property @code{supportNonIntegerFret} needs to be set @code{#t}
+in @code{Score}-context.
@code{FretBoards} will print those micro-tones only if they can be found in the
chosen settings for @code{stringTunings}, otherwise a warning (surpressed here)
will be printed and an empty @code{FretBoard} returned. Which should be the
\layout {
\context {
\Score
- noteToFretFunction = #(determine-frets #t)
+ supportNonIntegerFret = ##t
}
}
SCM
Beam::rest_collision_callback (SCM smob, SCM prev_offset)
{
+ if (!scm_is_number (prev_offset))
+ prev_offset = SCM_INUM0;
+
Grob *rest = unsmob<Grob> (smob);
if (scm_is_number (rest->get_property ("staff-position")))
- return scm_from_int (0);
+ return prev_offset;
- Real offset = robust_scm2double (prev_offset, 0.0);
+ Grob *stem = unsmob<Grob> (rest->get_object ("stem"));
- Grob *st = unsmob<Grob> (rest->get_object ("stem"));
- Grob *stem = st;
if (!stem)
- return scm_from_double (0.0);
+ return prev_offset;
+
Grob *beam = unsmob<Grob> (stem->get_object ("beam"));
if (!beam
|| !has_interface<Beam> (beam)
|| !Beam::normal_stem_count (beam))
- return scm_from_double (0.0);
+ return prev_offset;
Grob *common_y = rest->common_refpoint (beam, Y_AXIS);
+ (beam_count - 1) * beam_translation;
Real beam_y = stem_y - d * height_of_my_beams;
+ Real offset = robust_scm2double (prev_offset, 0.0);
Interval rest_extent = rest->extent (rest, Y_AXIS);
rest_extent.translate (offset + rest->get_parent (Y_AXIS)->relative_coordinate (common_y, Y_AXIS));
SCM, /* end */
SCM prev_offset)
{
- Real previous = robust_scm2double (prev_offset, 0.0);
+ if (!scm_is_number (prev_offset))
+ prev_offset = SCM_INUM0;
Grob *me = unsmob<Grob> (smob);
Grob *stem = unsmob<Grob> (me->get_object ("stem"));
if (!stem)
- return scm_from_double (previous);
+ return prev_offset;
Grob *beam = unsmob<Grob> (stem->get_object ("beam"));
if (!beam
|| !Beam::normal_stem_count (beam)
|| !is_direction (beam->get_property_data ("direction")))
- return scm_from_double (previous);
+ return prev_offset;
Real ss = Staff_symbol_referencer::staff_space (me);
Grob *right;
if (idx == (vsize) - 1 || my_stems.size () == 1)
- return scm_from_double (previous);
+ return prev_offset;
else if (idx == 0)
left = right = my_stems[1];
else if (idx == my_stems.size () - 1)
Real offset = beam_pos * ss / 2.0
- minimum_distance * beamdir
- me->extent (me, Y_AXIS)[beamdir];
+ Real previous = robust_scm2double (prev_offset, 0.0);
/* Always move by a whole number of staff spaces, always away from the beam */
offset = floor (min (0.0, (offset - previous) / ss * beamdir))
infos_[i + non_flag_dir].count (-non_flag_dir)),
infos_[i - non_flag_dir].count (non_flag_dir));
- infos_[i].beam_count_drul_[non_flag_dir] = count;
+ infos_[i].beam_count_drul_[non_flag_dir] = max(count, 1);
}
}
}
Percent_repeat_iterator::derived_mark () const
{
scm_gc_mark (child_list_);
+ Sequential_iterator::derived_mark ();
}
void
%}
-\version "2.19.31" % necessary for upgrading to future LilyPond versions.
+\version "2.19.32" % necessary for upgrading to future LilyPond versions.
\header{
title = "A scale in LilyPond"
%}
-\version "2.19.31" % necessary for upgrading to future LilyPond versions.
+\version "2.19.32" % necessary for upgrading to future LilyPond versions.
\header{
title = "A scale in LilyPond"
\accepts "TabStaff"
\accepts "VaticanaStaff"
- %% (determine-frets #t) would support micro-tones
- noteToFretFunction = #(determine-frets)
+ noteToFretFunction = #determine-frets
predefinedDiagramTable = ##f
soloText = #"Solo"
soloIIText = #"Solo II"
#, fuzzy
msgid ""
msgstr ""
-"Project-Id-Version: lilypond 2.19.31\n"
+"Project-Id-Version: lilypond 2.19.32\n"
"Report-Msgid-Bugs-To: http://post.gmane.org/post.php?group=gmane.comp.gnu."
"lilypond.bugs\n"
-"POT-Creation-Date: 2015-11-08 14:27+0000\n"
+"POT-Creation-Date: 2015-11-22 12:43+0000\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
msgid "%d: %s"
msgstr ""
-#: grob.cc:496
+#: grob.cc:486
#, c-format
msgid "ignored infinite %s-offset"
msgstr ""
msgid "Undefined parent event class `~S'"
msgstr ""
-#: define-markup-commands.scm:1102
+#: define-markup-commands.scm:1094
msgid "no systems found in \\score markup, does it have a \\layout block?"
msgstr ""
-#: define-markup-commands.scm:2943
+#: define-markup-commands.scm:2937
#, scheme-format
msgid "Cannot find glyph ~a"
msgstr ""
-#: define-markup-commands.scm:3419
+#: define-markup-commands.scm:3413
#, scheme-format
msgid "no brace found for point size ~S "
msgstr ""
-#: define-markup-commands.scm:3420
+#: define-markup-commands.scm:3414
#, scheme-format
msgid "defaulting to ~S pt"
msgstr ""
-#: define-markup-commands.scm:3665
+#: define-markup-commands.scm:3659
#, scheme-format
msgid "not a valid duration string: ~a"
msgstr ""
-#: define-markup-commands.scm:3878
+#: define-markup-commands.scm:3872
#, scheme-format
msgid "not a valid duration string: ~a - ignoring"
msgstr ""
msgid "assertion failed: ~S"
msgstr ""
-#: translation-functions.scm:378
+#: translation-functions.scm:379
#, scheme-format
msgid "Negative fret for pitch ~a on string ~a"
msgstr ""
-#: translation-functions.scm:381
+#: translation-functions.scm:384
#, scheme-format
msgid "Missing fret for pitch ~a on string ~a"
msgstr ""
-#: translation-functions.scm:424
+#: translation-functions.scm:427
#, scheme-format
msgid "No open string for pitch ~a"
msgstr ""
-#: translation-functions.scm:439 translation-functions.scm:451
+#: translation-functions.scm:442 translation-functions.scm:454
#, scheme-format
msgid "Requested string for pitch requires negative fret: string ~a pitch ~a"
msgstr ""
-#: translation-functions.scm:442
+#: translation-functions.scm:445
msgid "Ignoring string request and recalculating."
msgstr ""
-#: translation-functions.scm:454
+#: translation-functions.scm:457
msgid "Ignoring note in tablature."
msgstr ""
-#: translation-functions.scm:479
+#: translation-functions.scm:482
#, scheme-format
msgid "No string for pitch ~a (given frets ~a)"
msgstr ""
-#: translation-functions.scm:584
+#: translation-functions.scm:587
#, scheme-format
msgid ""
"No label for fret ~a (on string ~a);\n"
subdivided at @code{baseMoment} positions by only drawing one beam over the beat.")
(suggestAccidentals ,boolean? "If set, accidentals are typeset as
cautionary suggestions over the note.")
+ (supportNonIntegerFret ,boolean? "If set in @code{Score} the
+@code{TabStaff} will print micro-tones as @samp{2½}")
(systemStartDelimiter ,symbol? "Which grob to make for the start
of the system/@/staff? Set to @code{SystemStartBrace},
@code{SystemStartBracket} or @code{SystemStartBar}.")
object.")
(simple-Y ,boolean? "Should the Y placement of a spanner
disregard changes in system heights?")
- (size ,number? "Size of object, relative to standard size.")
+ (size ,number? "The ratio of the size of the object to its default
+size.")
(skip-quanting ,boolean? "Should beam quanting be skipped?")
(skyline-horizontal-padding ,number? "For determining the
vertical distance between two staves, it is possible to have a
(line (make-line-stencil underline-thick x1 y x2 y)))
(ly:stencil-add m line)))
+(define-markup-command (tie layout props arg)
+ (markup?)
+ #:category font
+ #:properties ((thickness 1)
+ (offset 2)
+ (direction UP)
+ (shorten-pair '(0 . 0)))
+ "
+@cindex tie-ing text
+
+Adds a horizontal bow created with @code{make-tie-stencil} at bottom or top
+of @var{arg}. Looks at @code{thickness} to determine line thickness, and
+@code{offset} to determine y-offset. The added bow fits the extent of
+@var{arg}, @code{shorten-pair} may be used to modify this.
+@var{direction} may be set using an @code{override} or direction-modifiers or
+@code{voiceOne}, etc.
+
+@lilypond[verbatim,quote]
+\\markup {
+ \\override #'(direction . 1)
+ \\tie \"above\"
+ \\override #'(direction . -1)
+ \\tie \"below\"
+}
+@end lilypond"
+ (let* ((line-thickness (ly:output-def-lookup layout 'line-thickness))
+ (thick (* thickness line-thickness))
+ (stil (interpret-markup layout props arg))
+ (x1 (car (ly:stencil-extent stil X)))
+ (x2 (cdr (ly:stencil-extent stil X)))
+ (y-ext (ly:stencil-extent stil Y))
+ (y (+ (* line-thickness offset direction)
+ ;; we put out zero for positive text-direction, to make it
+ ;; consistent with `underline-markup'
+ ;; TODO: this will be problematic for args like "Eng"
+ ;; fix it here _and_ in `underline-markup'
+ (if (negative? direction) 0 (cdr y-ext))))
+ (tie
+ (make-tie-stencil
+ (cons (+ x1 (car shorten-pair) line-thickness) y)
+ (cons (- x2 (cdr shorten-pair) line-thickness) y)
+ thick
+ direction)))
+ (ly:stencil-add stil tie)))
+
+(define-markup-command (undertie layout props arg)
+ (markup?)
+ #:category font
+ #:properties (tie-markup)
+ "
+@cindex undertie-ing text
+
+@lilypond[verbatim,quote]
+\\markup \\line {
+ \\undertie \"undertied\"
+ \\override #'(offset . 5)
+ \\override #'(thickness . 1)
+ \\undertie \"undertied\"
+ \\override #'(offset . 1)
+ \\override #'(thickness . 5)
+ \\undertie \"undertied\"
+}
+@end lilypond"
+ (interpret-markup layout (prepend-alist-chain 'direction DOWN props)
+ (make-tie-markup arg)))
+
+(define-markup-command (overtie layout props arg)
+ (markup?)
+ #:category font
+ #:properties (tie-markup)
+ "
+@cindex overtie-ing text
+
+Overtie @var{arg}.
+
+@lilypond[verbatim,quote]
+\\markup \\line {
+ \\overtie \"overtied\"
+ \\override #'(offset . 5)
+ \\override #'(thickness . 1)
+ \\overtie \"overtied\"
+ \\override #'(offset . 1)
+ \\override #'(thickness . 5)
+ \\overtie \"overtied\"
+}
+@end lilypond"
+ (interpret-markup layout (prepend-alist-chain 'direction UP props)
+ (make-tie-markup arg)))
+
(define-markup-command (box layout props arg)
(markup?)
#:category font
(procedure? markup?)
#:category other
"Apply the @var{procedure} markup command to @var{arg}.
-@var{procedure} should take a single argument."
- (let ((anonymous-with-signature (lambda (layout props arg) (procedure layout props arg))))
- (set-object-property! anonymous-with-signature
- 'markup-signature
- (list markup?))
- (interpret-markup layout props (list anonymous-with-signature arg))))
+@var{procedure} takes the same arguments as @code{interpret-markup}
+and returns a stencil."
+ (procedure layout props arg))
(define-markup-command (footnote layout props mkup note)
(markup? markup?)
1
#t))
+(define-public (make-bow-stencil
+ start stop thickness angularity bow-height orientation)
+ "Create a bow stencil.
+It starts at point @var{start}, ends at point @var{stop}.
+@var{thickness} is the thickness of the bow.
+The higher the value of number @var{angularity}, the more angular the shape of
+the bow.
+@var{bow-height} determines the height of the bow.
+@var{orientation} determines, whether the bow is concave or convex.
+@var{orientation} should be set to @val{-1} or @val{1}, other values are
+possible but will affect the bow's height as well.
+Both variables are supplied to support independent usage.
+
+Done by calculating a horizontal unit-bow first, then moving all control-points
+to the correct positions.
+Limitation: s-curves are currently not supported.
+"
+
+;;;; Coding steps:
+;;;; (1) calculate control-points for a "unit"-bow from '(0 . 0) to '(1 . 0)
+;;;; user settable `bow-height' and `thickness' are scaled down.
+;;;; (2) move control-points to match `start' and `stop'
+
+ (let* (;; we use a fixed line-width as border for different behaviour
+ ;; for larger and (very) small lengths
+ (line-width 0.1)
+ ;; `start'-`stop' distances
+ (dx (- (car stop) (car start)))
+ (dy (- (cdr stop) (cdr start)))
+ (length-to-print (magnitude (make-rectangular dx dy))))
+
+ (if (= 0 length-to-print)
+ empty-stencil
+ (let* (
+ ;;;; (1) calculate control-points for the horizontal unit-bow,
+ ;; y-values for 2nd/3rd control-points
+ (outer-control
+ (* 4/3 orientation (/ bow-height length-to-print)))
+ (inner-control
+ (* orientation
+ (- (abs outer-control) (/ thickness length-to-print))))
+ ;; x-values for 2nd/3rd control-points depending on `angularity'
+ (offset-index
+ (- (* 0.6 angularity) 0.8))
+ (left-control
+ (+ 0.1 (* 0.3 angularity)))
+ (right-control
+ (- 1 left-control))
+ ;; defining 2nd and 3rd outer control-points
+ (left-outer-control-point
+ (cons left-control outer-control))
+ (right-outer-control-point
+ (cons right-control outer-control))
+ ;; defining 2nd and 3rd inner control-points
+ (left-inner-control-point
+ (cons left-control inner-control))
+ (right-inner-control-point
+ (cons right-control inner-control))
+ (coord-list
+ (list
+ '(0 . 0)
+ left-outer-control-point
+ right-outer-control-point
+ '(1 . 0)
+ right-inner-control-point
+ left-inner-control-point))
+ ;;;; (2) move control-points to match `start' and `stop'
+ (moved-coord-list
+ (map
+ (lambda (p)
+ (cons
+ (+ (car start) (- (* (car p) dx) (* (cdr p) dy)))
+ (+ (cdr start) (+ (* (car p) dy) (* (cdr p) dx)))))
+ coord-list)))
+
+ ;; final stencil
+ (make-bezier-sandwich-stencil
+ moved-coord-list
+ (min (* 2 thickness) line-width))))))
+
+(define-public (make-tie-stencil start stop thickness orientation)
+ (let* (;; For usage in text we choose a little less `height-limit'
+ ;; than the default for `Tie'
+ (height-limit 0.7)
+ (ratio 0.33)
+ ;; taken from bezier-bow.cc
+ (F0_1
+ (lambda (x) (* (/ 2 PI) (atan (* PI x 0.5)))))
+ (slur-height
+ (lambda (w h_inf r_0) (F0_1 (* (/ (* w r_0) h_inf) h_inf))))
+ (width (abs (- (car start) (car stop))))
+ (angularity 0.5)
+ (height (slur-height width height-limit ratio)))
+ (make-bow-stencil start stop thickness angularity height orientation)))
+
(define-public (stack-stencils axis dir padding stils)
"Stack stencils @var{stils} in direction @var{axis}, @var{dir}, using
@var{padding}."
;; Create the dot-placement list for the grob
(set! (ly:grob-property grob 'dot-placement-list) placement-list)))
-(define*-public
- ((determine-frets #:optional (support-non-integer-fret? #f))
- context notes specified-info . rest)
+(define-public
+ (determine-frets context notes specified-info . rest)
"Determine string numbers and frets for playing @var{notes}
as a chord, given specified information @var{specified-info}.
@var{specified-info} is a list with two list elements,
@code{FretBoard} grob, and a fretboard will be
created. Otherwise, a list of @code{(string fret finger)} lists will
be returned.
-If the optional @var{support-non-integer-fret?} is set @code{#t}, micro-tones
-are supported for TabStaff, but not not for FretBoards."
+If the context-property @code{supportNonIntegerFret} is set @code{#t},
+micro-tones are supported for TabStaff, but not not for FretBoards."
;; helper functions
(and (or (and (not restrain-open-strings)
(zero? fret))
(>= fret minimum-fret))
- (if (and support-non-integer-fret? (null? rest))
+ (if (and
+ (ly:context-property context 'supportNonIntegerFret #f)
+ (null? rest))
(integer? (truncate fret))
(integer? fret))
(close-enough fret))))
(if (< this-fret 0)
(ly:warning (_ "Negative fret for pitch ~a on string ~a")
(car pitch-entry) string)
- (if (and (not (integer? this-fret)) (not support-non-integer-fret?))
+ (if (and
+ (not (integer? this-fret))
+ (not (ly:context-property context 'supportNonIntegerFret #f)))
(ly:warning (_ "Missing fret for pitch ~a on string ~a")
(car pitch-entry) string)))
(delete-free-string string)
projects / lilypond.git / commitdiff