Re: Articulate.ly: Fix mordent and prall timing for short notes (issue 190530043 by botialo...@gmail.com)
Patch on countdown for Jan 29th https://codereview.appspot.com/190530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)
Patch on countdown for Jan 29th https://codereview.appspot.com/194090043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for January 29th. 2015
Hello, Here is the current patch countdown list. The next countdown will be on January 29th. You can always view the most current countdown list here: http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=patch PUSH: David Nalesnik: Patch: Document 'scripts/add to relevant interfaces http://code.google.com/p/lilypond/issues/detail?id=4269 David Nalesnik: Patch: Missing spaces in lily/pure-from-neighbor-interface.cc http://code.google.com/p/lilypond/issues/detail?id=4268 David Nalesnik: Patch: doc fix for lily/stem-engraver.cc http://code.google.com/p/lilypond/issues/detail?id=4265 COUNTDOWN: James Lowe: Articulate.ly: Fix bug introduced in commit 88e1d22 (previously issue 4247) http://code.google.com/p/lilypond/issues/detail?id=4270 James Lowe: Enhancement: Reduce size of PDF files when included in *TeX documents http://code.google.com/p/lilypond/issues/detail?id=4251 WAITING: Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures http://code.google.com/p/lilypond/issues/detail?id=3918 Mike Solomon: Patch: Prevents vertical axis groups with empty skylines http://code.google.com/p/lilypond/issues/detail?id=3156 Mike Solomon: Patch: Removes the translate_axis call from axis-group-interface outside-staff positioning. http://code.google.com/p/lilypond/issues/detail?id=3134 David Kastrup: Patch: Implement music functions in Scheme rather than C++ http://code.google.com/p/lilypond/issues/detail?id=2716 Thank you, James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Articulate.ly: Fix mordent and prall timing for short notes (issue 190530043 by botialo...@gmail.com)
As requested I've changed the issue description. Peter C ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)
Reviewers: ,
Message:
Please review.
Description:
Issue 2535: Staccato on stem side alignment when other articulations are
present
The default positioning of staccato dots in combination with other
articulations
is poor, because the dot is positioned midway between the center of the
note head
and the stem, while all other scripts are centered on the note head.
A mechanism is needed to allow a staccato dot to be positioned
differently when alone
and when in combination with other articulations. The property
'toward-stem-shift
controls the alignment of scripts appearing on the side of the stem.
This patch
changes the type of 'toward-stem-shift to number-pair rather than
number. The first
member of the pair indicates the shift when alone, the second the shift
when the
script is contained by a ScriptColumn object. The vast majority of
articulations
default to '(0.0 . 0.0), indicating that they are always centered above
the note head
when on the stem side. Three articulations--staccato, staccatissimo,
and stopped--are
set to '(1.0 . 0.0), either directly above the stem or centered on the
note head,
ensuring that combinations like accent-staccato will be properly aligned
by default.
The previous default of 0.5 for staccato has been modified, in
accordance with Gould's
recommendation.
In order to allow a script to recognize the column organizing it, a
pointer to
ScriptColumn, called 'script-column, has been added to script-interface.
Please review this at https://codereview.appspot.com/196260043/
Affected files (+30, -15 lines):
M input/regression/script-shift.ly
M lily/script-column.cc
M lily/script-interface.cc
M scm/define-grob-properties.scm
M scm/output-lib.scm
M scm/script.scm
Index: input/regression/script-shift.ly
diff --git a/input/regression/script-shift.ly
b/input/regression/script-shift.ly
index
88f8f72f02524535330d94df8dc9bfa4001cc4a3..512fc9184617950dee0fe354aeb8286cfd912ac8
100644
--- a/input/regression/script-shift.ly
+++ b/input/regression/script-shift.ly
@@ -2,17 +2,24 @@
\header {
texidoc = "The @code{toward-stem-shift} property controls the precise
horizontal location of scripts that are placed above an upstem or below
-a downstem note (@code{0.0} means centered on the note head, @code{1.0}
-means centered on the stem).
+a downstem note. The first number of the pair indicates the shift
+applied when the script is alone, the second when present with other
+scripts. (@code{0.0} means centered on the note head, @code{1.0}
+means centered on the stem.)
"
}
-\version "2.17.6"
+\version "2.19.16"
\relative c''
{
- \override Script.toward-stem-shift = #0.0
+ \override Script.toward-stem-shift = #'(0.0 . 0.0)
a4^. c_.
- \override Script.toward-stem-shift = #1.0
+ \override Script.toward-stem-shift = #'(1.0 . 0.0)
a4^. c_.
+
+ a4^.^- c_._-
+
+ a4-\tweak toward-stem-shift #'(1.0 . 1.0) ^.^-
+ c4_. -\tweak toward-stem-shift #'(1.0 . 1.0) _-
}
Index: lily/script-column.cc
diff --git a/lily/script-column.cc b/lily/script-column.cc
index
0e797b543f2948cccd5495686ceb3895a76dd16c..2456f8b00b05d5c13e9969fce2bb5ea77fe408b5
100644
--- a/lily/script-column.cc
+++ b/lily/script-column.cc
@@ -39,6 +39,7 @@ Script_column::add_side_positioned (Grob *me, Grob
*script)
return;
Pointer_group_interface::add_grob (me, ly_symbol2scm ("scripts"),
script);
+ script->set_object ("script-column", me->self_scm ());
}
LY_DEFINE (ly_grob_script_priority_less, "ly:grob-script-priority-less",
Index: lily/script-interface.cc
diff --git a/lily/script-interface.cc b/lily/script-interface.cc
index
8778f5c6d316b8dbda9b4157aa81906260ac1fcf..bf0e96dacb554d0b9e4f0153936b1764f09a056f
100644
--- a/lily/script-interface.cc
+++ b/lily/script-interface.cc
@@ -153,6 +153,7 @@ ADD_INTERFACE (Script_interface,
"avoid-slur "
"direction-source "
"positioning-done "
+ "script-column "
"script-priority "
"script-stencil "
"side-relative-direction "
Index: scm/define-grob-properties.scm
diff --git a/scm/define-grob-properties.scm b/scm/define-grob-properties.scm
index
b850a18e8beb3c39cb0786c3b695916cae3e106f..77b392425f393cc6d5a9e5d703d8bf4da6aaf34c
100644
--- a/scm/define-grob-properties.scm
+++ b/scm/define-grob-properties.scm
@@ -1086,11 +1086,12 @@ in the list causes the corresponding tie to be
formatted
automatically.")
(to-barline ,boolean? "If true, the spanner will stop at the bar
line just before it would otherwise stop.")
- (toward-stem-shift ,number? "Amount by which scripts are shifted
-toward the stem if their direction coincides with the stem direction.
-@code{0.0} means keep the default position (centered on the note
-head), @code{1.0} means centered on the stem. Interpolated values are
-possible.")
+ (toward-stem-shift ,number-pair? "Amount by which scripts are shifted
+toward the stem if their direction coincides w
Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)
LGTM, thanks! https://codereview.appspot.com/196260043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4274: Fix a cyclic dependency in Rest_collision (issue 193590043 by nine.fierce.ball...@gmail.com)
Reviewers: ,
Description:
Rest_collision::calc_positioning_done now uses the pure height of
rests because the height of certain rests depends on their position on
the staff, which Rest_collision is responsible for adjusting.
There are differences in regression test output that I can not yet
explain. The differences do not appear when I run lilypond by itself,
so I'm expecting to have to dig up the exact command the regtests run.
I'm posting this review anyway in hopes that a reviewer will recognize
the problem.
Please review this at https://codereview.appspot.com/193590043/
Affected files (+5, -5 lines):
M lily/rest-collision.cc
Index: lily/rest-collision.cc
diff --git a/lily/rest-collision.cc b/lily/rest-collision.cc
index
7648f6d9a09825109e54f879442e3b3d1c2f2fca..c7c032eb399761f55aaa69181c06928f59747ad7
100644
--- a/lily/rest-collision.cc
+++ b/lily/rest-collision.cc
@@ -171,8 +171,8 @@ Rest_collision::calc_positioning_done (SCM smob)
common = common_refpoint_of_array (ordered_rests[UP], common,
Y_AXIS);
Real diff
-= (ordered_rests[DOWN].back ()->extent (common, Y_AXIS)[UP]
- - ordered_rests[UP].back ()->extent (common, Y_AXIS)[DOWN]) /
staff_space;
+= (ordered_rests[DOWN].back ()->pure_height (common, 0, 0)[UP]
+ - ordered_rests[UP].back ()->pure_height (common, 0, 0)[DOWN])
/ staff_space;
if (diff > 0)
{
@@ -189,8 +189,8 @@ Rest_collision::calc_positioning_done (SCM smob)
{
for (vsize i = ordered_rests[d].size () - 1; i-- > 0;)
{
- Real last_y = ordered_rests[d][i + 1]->extent (common,
Y_AXIS)[d];
- Real y = ordered_rests[d][i]->extent (common, Y_AXIS)[-d];
+ Real last_y = ordered_rests[d][i + 1]->pure_height (common,
0, 0)[d];
+ Real y = ordered_rests[d][i]->pure_height (common, 0, 0)[-d];
Real diff = d * ((last_y - y) / staff_space);
if (diff > 0)
@@ -221,7 +221,7 @@ Rest_collision::calc_positioning_done (SCM smob)
continue;
Grob *common = common_refpoint_of_array (notes, rcol, Y_AXIS);
- Interval restdim = rest->extent (common, Y_AXIS);
+ Interval restdim = rest->pure_height (common, 0, 0);
if (restdim.is_empty ())
continue;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4274: Fix a cyclic dependency in Rest_collision (issue 193590043 by nine.fierce.ball...@gmail.com)
Are you sure there is a cycle?
Rest_collision::calc_positioning_done now uses the pure
height of rests because the height of certain rests depends
on their position on the staff, which Rest_collision is
responsible for adjusting.
Rest_collision does use the height of the rests to determine the height
of the rests, but I do not see where calling the Rest::height() function
can call Rest_collision() cyclically.
This calculation seems to be of the type
h = 3;
if (moon is full)
h = h + 2;
Much of LilyPond layout code is done through function calls, so there is
often risk of cycles like
int h(void) {
int ret = 3;
if (moon is full)
ret = h() + 2;
return ret;
}
but I don't see how that can happen here.
Is there some LilyPond input that causes infinite recursion or gives the
error message from the trap for cyclic dependencies ?
https://codereview.appspot.com/193590043/diff/1/lily/rest-collision.cc
File lily/rest-collision.cc (right):
https://codereview.appspot.com/193590043/diff/1/lily/rest-collision.cc#newcode195
lily/rest-collision.cc:195: Real diff = d * ((last_y - y) /
staff_space);
The idea here seemed to be that any outer-voice rests are offset based
on inner-voice rests, which were just placed by the translate() call
above. pure_height() seems to freshly look up the stencils so it would
ignore any previous positioning. The result is used in the translate()
below which offsets the rests relative to their most recent position, so
the old code using the most recent positions seems correct.
https://codereview.appspot.com/193590043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)
It seems to me like this number-pair consists of two settings that would almost always be adjusted independently. Wouldn't it make more sense to make a separate property here? That way, the user would not need to remember and restate the setting he is not interested in. https://codereview.appspot.com/196260043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)
Aaaand another thought: wouldn't it make more sense instead of having independent shifts for "with other articulations" and "without other articulations" when the articulation closest to the notehead is responsible for aligning the whole stack of articulations? Which would be the extreme case of a weighted average where articulations closest to the notehead count most towards alignment. But I suspect that looking at more than just the closest articulation would likely be overkill and not an actual improvement. https://codereview.appspot.com/196260043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2535: Staccato on stem side alignment when other articulations are present (issue 196260043 by david.nales...@gmail.com)
On 2015/01/27 07:26:53, dak wrote: It seems to me like this number-pair consists of two settings that would almost always be adjusted independently. Wouldn't it make more sense to make a separate property here? That way, the user would not need to remember and restate the setting he is not interested in. IMHO it's better to logically stick stuff together. We already have far too much properties, and in this particular case I doubt that the user will change the values very often so I think the benefits of having a single property are exceeding the potential disadvantages. https://codereview.appspot.com/196260043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
