David Kastrup [Sun, 13 Jul 2014 13:30:03 +0000 (15:30 +0200)]
Issue 4009: \retrograde fails on slurs
The section "Retrograde" in the Notation Reference is affected.
This became likely exposed with issue 2240; the corresponding
regtest does not cover it. The problem was existent previously
for slurs and other spans inside of chords.
Added two Clefs to notation-appendices.itely - Clef Styles
\clef "G2" and \clef moderntab
Removed excessive brackets in the @lilypond constructions and
updated the '\clef tab' entry so that it engraves correct out
put by adding a \new TabStaff block in the @lilypond example.
Mark Polesky [Fri, 11 Jul 2014 06:03:06 +0000 (23:03 -0700)]
Issue 3991: \magnifyMusic: surrender to issues 3987 and 3990.
Until issues 3987 and 3990 are fixed, automatic scaling
of horizontal spacing with \magnifyMusic is broken. This
patch turns the feature off, and adds a note in the docs.
Janek Warchoł [Mon, 30 Jun 2014 20:14:16 +0000 (22:14 +0200)]
Issue 2462: don't change ideal spacing when adding a rod
When objects like lyrics are added to the PaperColumns, LilyPond inserts
rods between these columns to ensure that the objects won't overlap.
However, the ideal distance should remain unchanged. For example, in
notes in 2nd measure have long lyrics attached to them - min_distance_
of the springs between these columns should be adjusted, but distance_
(the ideal distance) should not: it should be the same as for notes
with short lyrics. When the line is stretched so much that the minimum
distances are not involved, the springs between notes in both measures
should behave (almost) identical.
Note that there are more such problems in the springs code, for example
in merge_springs. The code should be rewritten, but that's not trivial.
Since this one-liner fixes some instances of the problem without any bad
side-effects, it makes sense to include it separately.
doc: update make-simple-closure example in Extending (Issue 3993)
After improvements in Self_alignment_interface::aligned_on_parent
(in particular after fixing issue 3254) it was possible to simplify
default X-offset values for several grobs, so that they didn't have
to use make-simple-closure (see e.g. commit 1d765020f8679958). This
made an example in Extending 2.7 obsolete, so I'm replacing it with
one that still uses make-simple-closure.
Janek Warchoł [Wed, 27 Mar 2013 16:20:03 +0000 (17:20 +0100)]
Issue 2245: always align dynamics and lyrics on "main" notehead
Until now, LyricTexts and DynamicTexts had their X-parents set to
the first NoteHead in the NoteColumn. This resulted in inconsistent
alignment - placement of lyrics and dynamics depended on the order
of notes in the input:
% this was aligned differently
{ <f' g'>1\p <g' f'>\p }
\addlyrics { la la }
By using NoteColumns themselves as the X-parents, we make sure that
the input order won't matter. Since the NoteColumn contains all NoteHeads
(including suspended ones, which usually should be ignored when aligning),
as well as Flags and some other objects, we cannot use its X-extent directly -
instead, we add a function for calculating X-extent of the "main" part of the
NoteColumn, i.e. X-extent of the non-suspended NoteHeads (represented by the
NoteHead furthest away from the stem).
James Lowe [Tue, 1 Jul 2014 20:32:09 +0000 (21:32 +0100)]
Doc: NR 4.5.4 Change Node name from 'Line length' to 'Line width'
Issue 3982
Change Node name from 'Line length' to 'Line width'.
In the Notation Reference, this page is called
"Line length" but the property that it covers
(among others) is called "line-width." Seems like
it would be better if the title of the page was
renamed "Line width" for greater consistency.
David Kastrup [Thu, 3 Jul 2014 08:22:37 +0000 (10:22 +0200)]
Issue 3986: \displayScheme broken
\displayScheme \markup \null
failed because a markup following an omitted optional argument (here the
optional output port) was backed up erroneously with the token type
LYRIC_ELEMENT only to be used in lyrics mode.
The optional argument was introduced with issue 2067 in version 2.19.0.
The actual underlying parser error triggered by this, however, is quite
older and originates from
David Kastrup [Thu, 5 Jun 2014 18:34:14 +0000 (20:34 +0200)]
Issue 3983: Avoid define-public and define*-public with curried definitions
Regarding curried definitions, GUILE has problems with define-public
before version 2.0.10, and with define*-public even later.
define-safe-public is implemented by LilyPond itself rather than the
(ice-9 curried-definitions) module and is unproblematic.
This is basically a cop-out since juggling with overriding bugfix
definitions of define-public is a distraction for getting GUILEv2
migration under way that we can do without.
Make DynamicTexts, TextScripts and many other grobs use aligned_on_parent,
which makes their behaviour consitent, predictable and thus more user-friendly.
Janek Warchoł [Mon, 23 Jun 2014 21:30:49 +0000 (23:30 +0200)]
TextScript, CombineTextScript: use aligned_on_parent
I think this makes more sense than just using "self-alignment".
It makes these grobs consistent with Lyrics and Dynamics, and
allows users to override their alignment more predictably.
Expected changes in output: TextScripts and CombineTextScripts
will be aligned slightly different when the user sets self-alignment-X
explicitly (parent notehead will be included in alignment, as in Lyrics).
Default placement should remain the same.
I'm also changing one regtest, just to make sure that despite slightly
changed alignment the markups will stick out far enough to the left.
Janek Warchoł [Mon, 23 Jun 2014 21:04:26 +0000 (23:04 +0200)]
Replace XY-offset closures with aligned_on_parent where possible
It doesn't make sense to specify placement using multiple added
callbacks or closures when we can use aligned_on_parent. What's
more, aligned_on_parent should expose more consistent interface
for the users - affected grobs should now behave similarly to
LyricTexts and DynamicTexts. For example, this
Janek Warchoł [Fri, 29 Mar 2013 23:11:28 +0000 (00:11 +0100)]
Clean up DynamicText horizontal alignment.
Until now, DynamicText alignment was messy, as there were 3 different
callbacks involved - some of them interacting in a confusing way:
- in define-grobs.scm, X-offset property was initialized to
ly:self-alignment-interface::x-aligned-on-self,
- Dynamic_engraver called set_center_parent on every DynamicText
attached to a note, so that half a NoteHead width was always added
to its X-offset (producing confusing results for example when
user requested dynamics to be left-aligned),
- DynamicTexts living in a Dynamics context used a completely
different offset callback, which aligned them on NoteColumns.
Since aligned_on_parent is now able to correctly align grobs
with PaperColumn parents (issue 3254), we can use it for all
DynamicTexts and have a single interface for the job.
Expected changes in output: DynamicTexts in Dynamics context
aligned to suspended noteheads may be placed up to 1/4 NoteHead
width further to the right. This shouldn't be a problem.
Patrick Schmidt [Sat, 28 Jun 2014 20:24:23 +0000 (21:24 +0100)]
Reg Tests: XML 01b has an incorrect number of measures
Issue 3973
01b-Pitches-Intervals.xml from the Unofficial MusicXML
test suite contains only a single measure in MusicXML,
but there should be 41.
musicxml2ly is very tolerant here so the error doesn’t
show in the pdf.
Added missing <measure> elements
Fixed a typo in the title
Added missing <accidental> elements (They represent
the actual notated accidentals. Without these elements
there shouldn’t be any visible accidentals. So this is
actually a bug in musicxml2ly. The bug doesn’t show here
because musicxml2ly interprets the <alter> element which
represents the sounding pitch of a note.)
Janek Warchoł [Sun, 29 Jun 2014 20:58:45 +0000 (22:58 +0200)]
Rename argument to avoid preprocessor problems
Before this change, we were getting the following error with GUB:
/home/gub/gub/target/mingw/src/
lilypond-git.sv.gnu.org--lilypond.git-release-unstable/
lily/include/paper-column.hh:62:
error: expected identifier before ',' token
/home/gub/gub/target/mingw/src/
lilypond-git.sv.gnu.org--lilypond.git-release-unstable/
lily/include/paper-column.hh:62:
error: two or more data types in declaration of 'parameter'
David Kastrup suspects that the library/compiler used for bootstrapping
has a macro or reserved word defined for "interface" - changing the name
makes the problem go away.
James Lowe [Sat, 21 Jun 2014 12:38:59 +0000 (13:38 +0100)]
Doc: Usage: Added a clarifying paragraph about Error Messages
Issue 3873
Added a clarifying paragraph explaining that (the same)
diagnostics message can occur in multiple places for
(the same) input depending on the type and its context.
James Lowe [Sat, 21 Jun 2014 20:28:55 +0000 (21:28 +0100)]
Doc: NR Section 4.3 - reformatting as per CG Guidelines
Start of issue 3960
This section does not adhere to many aspects of the Contributors'
Guide Documentation policies.
This specific patch therefore is the 'first stage' of this issue
so as to clean up the section before then making changes to
the technical information. There is too much to do for a single patch,
so I expect to have to make a few more additional patches to tidy this
section up completely before the issue can be properly closed.
This patch includes:
* Correct Line lengths
* Added @seealsos where appropriate
* Re-ordered some of the @nodes so that they are grouped more logically
* Moved @subsections to @unnumberedsubsubsecs:
A few of these sections seem to 'talk through the code' so may
need to be improved later on. However, for now I have moved these
subsections to unnumberedsubsubsec under the main 'Page Breaking'
node. Moved one of these new unnumberedsubsucsecs around so that
the sections on the different breaks come before the turning one.
* Created new Snippet:
One subsection was really a glorified snippet so I have made it into
one.
use X-parents to align MMRNumbers, MMRTexts and PercentRepeatCounters
It makes more sense to use X-parents than Y-parents for horizontal
alignment. To be able to do this, we have to ensure that X-parents of
MultiMeasureRestNumber, MultiMeasureRestText and PercentRepeatCounter
won't be overwritten by set_bound (these grobs are spanners). We can
do this because parents of these grobs are spanners as well.
James Lowe [Tue, 17 Jun 2014 23:35:39 +0000 (00:35 +0100)]
NR 1.1.3 and Changes update w/ new Clef Appendix
Updated changes.tely to show the extra variations on the new Clef glyphs
(i.e. there are 4 separate glyphs but there are different \clef names using
those glyphs but in different positions.
Added a new Appendix to the NR showing all the standard \clef types
(not including 'ancient music' clefs) in a table, illustrating their
names and where middle c sits relative to the clef. Because of this
I have modified 1.1.3 referencing this appendix instead of listing
them all directly in the Clef section. Also added two useful Clef
related snippets that were already created.
Janek Warchoł [Sun, 17 Mar 2013 20:22:32 +0000 (21:22 +0100)]
Issue 3254: align unassociated lyrics using NoteColumn extent.
This makes unassociated lyrics behave consistently with
associated lyrics. Until now, "standalone" lyrics
were left-aligned (more precisely: their X-offset was 0);
changing self-alignment-X didn't have any effect on them.
Now it's possible to specify their alignment, like with
associated lyrics.
Also, this changes how issue 104 was resolved (see 0b14e8b2e122d) -
alignment of syllables that are associated to a context without
noteheads is no longer aborted - and solves issue 247.
Later on, these changes should allow using aligned_on_parent for
other grobs (such as DynamicTexts).
Expected changes in output: all lyrics should be centered by default.
Thomas Morley [Mon, 26 May 2014 21:44:30 +0000 (23:44 +0200)]
Color and/or parenthesize single dots in fret-diagrams
Issue 2752
Makes it possible to color and/or parenthesize single dots in
fret-diagram-verbose
Introducing two properties for use in fret-diagram-details
- fret-label-horizontal-offset
affecting the fret-label-indication, like the existing
`fret-label-vertical-offset'
- paren-padding
affecting the padding of the parenthesis
David Kastrup [Thu, 12 Jun 2014 11:13:16 +0000 (13:13 +0200)]
Issue 3950: \relative inside \unfold doesn't cause an extra staff anymore
This is a result of issue 3797. It might be nice to come up with
another example demonstrating undesired implicit context creation, but
this example was rather a bug than a direct consequence of well-defined
but possibly sometimes inconvenient default behaviors.
Mark Polesky [Sat, 14 Jun 2014 02:25:19 +0000 (19:25 -0700)]
Issue 2950: Update substitution function example in LM.
The old example illustrated the principle well, until skylining
code was added. This change makes the example's point clear in
light of the new vertical spacing code.