Simon Albrecht [Tue, 8 Sep 2015 13:54:56 +0000 (14:54 +0100)]
Doc: NR - Improve wording in 'Changing Spacing'
Issue 4589
The paragraph from "Avoid (or reduce)"
in spacing.itely used 'for example'
twice in a row. The description of the
'volta bracket' issue was unclear in
terminology and phrasing.
David Kastrup [Sun, 6 Sep 2015 12:45:52 +0000 (14:45 +0200)]
Remove TODO comment about crashing music functions in .scm
After issue 4442, there is no lexical tie of #{...#} to the current parser,
and even before that, with standard parser/location arguments there should
not have been any problems after issue 3153 at the latest.
Thomas Morley [Sun, 23 Aug 2015 13:24:06 +0000 (15:24 +0200)]
Clear fret-diagram- and harp-pedal-input-strings from whitespace
issue 4575
Whitespace-characters are deleted before further processing.
Allows for
\markup \fret-diagram #"s:2;h:5;
6-3;5-5;4-5;3-4;2-3;1-x;"
Also adding errors for typos in fret-diagram with a meaningful message:
\markup \fret-diagram #"s:2;g:r;
6-3;5-5;4-5;3-4;2-3;1-x;"
will return:
fatal error: Unhandled entry in fret-diagram "g:r" in "g:r"
This error would not apply, if something for #\g would be defined
in fret-parse-definition-string somewhere in the future.
Then, the message would be:
fatal error: Unhandled entry in fret-diagram "r" in "g:r"
David Nalesnik [Wed, 26 Aug 2015 14:46:07 +0000 (09:46 -0500)]
Scheme function to draw lines based on grob layout
A number of C++ stencil callbacks use Line_interface::line to draw
lines based on line-interface properties defining a particular grob.
This allows control of aspects such as line style (based on the setting
of Grob.style) and fine-tuning of dashed lines through dash-fraction
and dash-period.
This patch gives access to Line_interface::line in Scheme through the
callback ly:line-interface::line. (The simpler name ly:line was ruled
out in an effort to distinguish it from other functions such as
ly:bracket and ly:circle which do not take a grob argument.) Users
will be able to create custom stencils with more functionality
(including rewriting certain C++ callbacks--such as Hairpin::print--to
allow for easy modifications without loss of capability.)
David Nalesnik [Mon, 24 Aug 2015 14:13:31 +0000 (09:13 -0500)]
Don't print redundant flags in chords
This patch adds a check to lily/stem-engraver.cc which ensures that only
one Flag grob appears for a given Stem grob. Previously, a flag was created
and printed for each note of a chord.
articulate.ly: update documentation, add support for portato
This changeset updates the articulate.ly script documentation on the supported
articulations with a description of ac:staccatissimoFactor, and adds
ac:portatoFactor for shortening notes marked \portato, and slurred notes marked
\staccato. The default value for ac:portatoFactor is 3/4 (to match the
current default shortening factor for notes marked \portato when not using
articulate.ly).
Dan Eble [Thu, 20 Aug 2015 23:06:03 +0000 (19:06 -0400)]
Issue 4550 (2/2) Avoid "using namespace std;" in included files
These changes are produced by a rather long shell script that is
posted in the code review for this issue. Summary:
* remove "using namespace std;" everywhere
* add "std::" in *.hh and other included files
* add "std::" to functions and lesser-used types in *.cc files
Dan Eble [Sat, 8 Aug 2015 17:11:02 +0000 (13:11 -0400)]
Issue 4550 (1/2) Avoid "using namespace std;" in included files
These are manual changes in preparation for an automated removal of
"using namespace std;".
Mostly these are additions of using-declarations for commonly used
types and containers (e.g. std::string, std::vector) to *.cc files so
that they will continue to build after the big removal.
David Kastrup [Tue, 11 Aug 2015 17:09:47 +0000 (19:09 +0200)]
Issue 680: clusters collapse when applied to repeated chords
This replaces the rather shaky calculation of rounded polygon
outlines (unchanged since 2002AD) with something grounded somewhat
firmer in vector algebra. As a result, the rather flowery
interpretation of clusters so far (previously confused by concave
corners and other things) is becoming a lot more boring.
Set the sequence name in MIDI using title information from
\header block
issue 4539
This patch adds support for setting the MIDI sequence name for MIDI output files
using the value of the "midititle" field from a relevant \header block, and
falling back to using the "title" field if "midititle"
has not been defined. (This should be analogous to how "pdftitle" and "title"
work for customizing PDF metadata.)
The purpose of the change is to improve the previous behavior where the name of
every MIDI sequence created by LilyPond used to be shown by MIDI synthesizers as
"control track" (previously, this string was hard-coded as the name of every
initial track of MIDI files created by LilyPond by Control_track_performer).
The patch
* extends every Performance instance with a reference to a \header block
associated with the performance, adds Scheme library routines for getting and
setting the associated \header (modeled after corresponding routines available
for the Score class), and updates the Book::process_score function to initialize
the header information of Performance objects attached to a score;
* adds a "name" parameter to the Performance output routines, used for
updating the track name in the performance's first Audio_staff (assumed to
represent the control track) before outputting MIDI; and
* changes the write-performances-midis function (in scm/midi.scm) to query the
MIDI sequence name for a performance from the performance's \header block
(adapted from the handle-metadata function in scm/framework-ps.scm).
* adds two regtests
Due to conf file loading order, generic font aliases
`serif', `sans-serif', 'monospace' were unavailable
in LilyPond default fonts definition.
So the glyphs that are not contained
in the list of font definition,
like Japanese glyphs were used unexpected font.
This commit changes
LilyPond default fonts definition loading order
for enabling the aliases.