from:"lemniskata . bernoullego"


On 2013/09/01 16:49:59, dak wrote:

https://codereview.appspot.com/13270048/diff/1/lily/parser.yy
File lily/parser.yy (right):



https://codereview.appspot.com/13270048/diff/1/lily/parser.yy#newcode2328

lily/parser.yy:2328: | SCM_IDENTIFIER
On 2013/09/01 16:25:39, Janek Warchol wrote:
> just curious: this SCM_IDENTIFIER is for things like #LEFT?



No.  It's for \xxx or $xxx kind of things not belonging in any other
xxx_IDENTIFIER category.  #LEFT would be SCM_TOKEN instead (and is

covered by

embedded_scm_arg).


ah,ok.


https://codereview.appspot.com/13270048/diff/1/lily/parser.yy#newcode2351

lily/parser.yy:2351: // not of the kind requiring the full closedness

folderol.

On 2013/09/01 16:25:39, Janek Warchol wrote:
> Please avoid using uncommon words like "folderol".  They are funny,

but only

for
> native speakers ;-)



The dictionary offers "humbug", "balderdash", "poppycock", "rubbish",

"tripe",

"trumpery", "trash", "wish-wash", "applesauce", "codswallop" as

alternative

words but most of them have not quite the same connotations, and it's

not like

those that are similar in meaning are in more common use.


uh, ok.


While most code passages in LilyPond are documented without venturing

beyond the

most common 1000 English words (mostly because they are not venturing

beyond any

word at all), I think this should already be a notable improvement

over the

standard state.


Indeed, i've noticed the extensive comments and i do appreciate them!

Janek

https://codereview.appspot.com/13270048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

outside-staff-padding: add just one pad; issue 2910 (issue 10329043)


Could you add some information in the commit message explaining why had
you changed the default values?

https://codereview.appspot.com/10329043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: make sure that AmbitusLine is visible for small ambits (issue 4609041)


Just to let you know: i've tested the patch on a bunch of simple SATB
scores and the ambits look way better.

https://codereview.appspot.com/4609041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

parser.yy: allow "scalar" to be a negative literal number (issue 13270048)


LGTM


https://codereview.appspot.com/13270048/diff/1/lily/parser.yy
File lily/parser.yy (right):

https://codereview.appspot.com/13270048/diff/1/lily/parser.yy#newcode2328
lily/parser.yy:2328: | SCM_IDENTIFIER
just curious: this SCM_IDENTIFIER is for things like #LEFT?

https://codereview.appspot.com/13270048/diff/1/lily/parser.yy#newcode2351
lily/parser.yy:2351: // not of the kind requiring the full closedness
folderol.
Please avoid using uncommon words like "folderol".  They are funny, but
only for native speakers ;-)

https://codereview.appspot.com/13270048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: make sure that AmbitusLine is visible for small ambits (issue 4609041)

2013-08-30 Thread lemniskata . bernoullego



https://codereview.appspot.com/4609041/diff/29002/input/regression/ambitus-gap.ly
File input/regression/ambitus-gap.ly (right):

https://codereview.appspot.com/4609041/diff/29002/input/regression/ambitus-gap.ly#newcode5
input/regression/ambitus-gap.ly:5: note heads are set by the @code{gap}
property. Also, ambitus line
On 2013/08/30 04:57:30, Keith wrote:

"By default, @code{gap} is a function that reduces the gap for small

intervals,

so line remains visible."



We cannot say "Also," because if I set the gap property to 0.4, then

the line

will *not* be visible in fourth.


Done.

https://codereview.appspot.com/4609041/diff/29002/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/4609041/diff/29002/scm/output-lib.scm#newcode1252
scm/output-lib.scm:1252: (if (and (ly:grob-array? heads)
On 2013/08/30 04:57:30, Keith wrote:

You should have an 'else' case (if   ) so that if

the test

ever fails you return some value; otherwise the user gets a mysterious

error

message.


Done.

https://codereview.appspot.com/4609041/diff/29002/scm/output-lib.scm#newcode1258
scm/output-lib.scm:1258: (max-gap (ly:grob-property grob 'maximum-gap
2))
On 2013/08/30 04:57:30, Keith wrote:

The defaults seem strange.  They should be typical values, otherwise

people get

confused.  Is 'max-gap normally 2 ?


Good catch, this was a typo.  Done.

https://codereview.appspot.com/4609041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: include lines in breve X-extent (issue 1814) (issue 4931043)

2011-09-06 Thread lemniskata . bernoullego

Reviewers: janek, Bertrand Bordage, MikeSol, J_lowe, Ian Hulin (gmail),  
graham_percival-music.ca,


Message:
On 2011/09/06 16:26:40, Bertrand Bordage wrote:

On 2011/09/06 08:54:40, janek wrote:
> I'm not sure what you mean.  Are you saying that i should assign (i

* (gap +

> stemthick), 0) to a variable in the for loop?  I.e. sth like
>
>for i := 0 step 1 until linecount - 1:
>foobar := (i * (gap + stemthick), 0);
>draw_gridline (z1 - foobar,
>   z2 - foobar,
>   stemthick);
>draw_gridline (z3 + foobar,
>   z4 + foobar,
>   stemthick);
>endfor;
> ?



Yes, that would be cleaner and easier to understand.


Done (http://codereview.appspot.com/4986042/)

Description:
include lines in breve X-extent (issue 1814)

char box of breve glyphs is widened to include
the lines, not only notehead.  This will allow
Lily to calculate collisions with breves
correctly.  It shouldn't change how breves
are aligned in note columns.

Please review this at http://codereview.appspot.com/4931043/

Affected files:
  M mf/feta-noteheads.mf


Index: mf/feta-noteheads.mf
diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index  
a58e4bc89a7a6c607a3da1dea2478ecce9b8ba0f..1c208b651d9a248bb48b10deb05c3ff63d4c11d5  
100644

--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -164,6 +164,11 @@ def draw_brevis (expr linecount,  
line_thickness_multiplier) =

define_whole_blacker_pixels (stemthick);

% Breves of smaller design sizes should have their lines
+   % farther apart.
+   gap# := (0.95 - 0.008 * design_size) * stemthick#;
+   define_pixels (gap);
+
+   % Breves of smaller design sizes should have their lines
% farther apart (the overlap should be smaller).
fudge = hround (blot_diameter
* min (max (-0.15,
@@ -175,6 +180,11 @@ def draw_brevis (expr linecount,  
line_thickness_multiplier) =

draw_outside_ellipse (1.80, 0, 0.707, 0);
undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#);

+   set_char_box (stemthick# * linecount + gap# * (linecount - 1),
+ width# + stemthick# * linecount + gap# * (linecount - 1),
+ noteheight# / 2,
+ noteheight# / 2);
+
pickup pencircle scaled stemthick;

% Breves of smaller design sizes should have their lines longer.
@@ -194,20 +204,17 @@ def draw_brevis (expr linecount,  
line_thickness_multiplier) =

rt x1 - fudge = 0;
x1 = x2;

-   fudge + lft x3 = w;
+   fudge + lft x3 = width;
x4 = x3;
y4 = y2;
y3 = y1;

-   % Breves of smaller design sizes should have their lines
-   % farther apart.
-   line_distance := (1.95 - 0.008 * design_size) * stemthick;
for i := 0 step 1 until linecount - 1:
-   draw_gridline (z1 - (i * line_distance, 0),
-  z2 - (i * line_distance, 0),
+   draw_gridline (z1 - (i * (gap + stemthick), 0),
+  z2 - (i * (gap + stemthick), 0),
   stemthick);
-   draw_gridline (z3 + (i * line_distance, 0),
-  z4 + (i * line_distance, 0),
+   draw_gridline (z3 + (i * (gap + stemthick), 0),
+  z4 + (i * (gap + stemthick), 0),
   stemthick);
endfor;
 enddef;



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: modifying default behaviour of tremolo slashes (issue 4636081)

2011-08-22 Thread lemniskata . bernoullego


Regtest added.


http://codereview.appspot.com/4636081/diff/38001/lily/stem-tremolo.cc
File lily/stem-tremolo.cc (right):

http://codereview.appspot.com/4636081/diff/38001/lily/stem-tremolo.cc#newcode118
lily/stem-tremolo.cc:118: shape = ly_symbol2scm ("beam-like");
On 2011/08/11 20:05:10, Neil Puttock wrote:

this is redundant unless you want to add a warning for invalid shape

setting

(you only check for rectangle below; anything else falls through to

Lookup::beam

())


True, but shouldn't we leave it to make the code more logical and
elegant (and in case we want to expand it in the future)?

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: changing shape of the G clef (issue 4664070)

2011-08-22 Thread lemniskata . bernoullego


pushed as e795110331497fbf46a7d61ed6ed73a9da4ae9c5

http://codereview.appspot.com/4664070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds a glyph for tied lyrics. (issue4808074)

2011-08-08 Thread lemniskata . bernoullego


I'd make the tie slightly shorter.  I find it awkward that two adjacent
ties collide so easily, for example here
{
  \time 3/4
  \relative c' { c2 e4 g2 e4 }
  \addlyrics { gran- de_a- mi- go }
  \addlyrics { pu- "ro y ho-" nes- to }
  \addlyrics { pu- ro~y~ho- nes- to }
}
(example from documentation), or in the example you attached on the
tracker issue page.

cheers,
Janek

http://codereview.appspot.com/4808074/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Added \compoundMeter function to NR (issue4837050)

2011-08-08 Thread lemniskata . bernoullego

http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely#newcode1555
Documentation/notation/rhythms.itely:1555: shown durations are
multiplied by 3/5 -- as 3/5 * 10/8 = 3/4.  It may be
On 2011/08/07 20:33:38, J_lowe wrote:

On 2011/08/07 15:24:44, Trevor Daniels wrote:
> I prefer brackets to show these parenthetical comments:
> (because 2/3 * 9/8 = 3/4)

I have no strong feelings either way. So Done.

I like this.

http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely#newcode1643
Documentation/notation/rhythms.itely:1643: come before it indicate the
beat value.
On 2011/08/07 20:33:38, J_lowe wrote:

On 2011/08/07 15:24:44, Trevor Daniels wrote:
> I think it's clearer to say top and bottom of the time signature:
> ... last number in the list is placed at the bottom of the time

signature and

> the numbers that come before it are placed as a summation at the

top.  All but

> the last number indicate the stress groupings and sum to the

duration of the

> measure.

hmmm..I still think that is a bit awkward - I'm not sure 'summation'

comes over

well for non-native English speakers looking at the NR. I also don't

feel the

last sentence is necessary if the @lilyponds are good enough (that and

we talk

about beaming anyway later). See what you think of my very simple

change.

I agree that the last sentence suggested by Treveor isn't necassary.
I think that if we change "summation" to "sum" in his proposal, it will
be understood by people.  In Wiktionary i see that word for sum is
similar in many languages.

http://codereview.appspot.com/4837050/diff/14002/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/4837050/diff/14002/Documentation/notation/rhythms.itely#newcode1643
Documentation/notation/rhythms.itely:1643: before it, the bottom
numbers.
It's the other way round - Last number goes to the bottom.

http://codereview.appspot.com/4837050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds a glyph for tied lyrics. (issue4808074)

2011-08-07 Thread lemniskata . bernoullego


I've created tracker issue:
http://code.google.com/p/lilypond/issues/detail?id=1807

Could you upload some pngs showing before/after output?  It would be
helpful for those who cannot build the patch themselves.

http://codereview.appspot.com/4808074/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Added \compoundMeter function to NR (issue4837050)

2011-08-07 Thread lemniskata . bernoullego


overall LGTM


http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/4837050/diff/15001/Documentation/notation/rhythms.itely#newcode1643
Documentation/notation/rhythms.itely:1643: come before it indicate the
beat value.
Funny, i'd say that "beat value" and "note value" mean the same...
I'd write "indicate the number of beats."  However, this results in
excessive repetition of word "number".

http://codereview.appspot.com/4837050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixes bad slur heights by limiting fit_factor to the interior of slurs. (issue4810072)

2011-08-06 Thread lemniskata . bernoullego


Hi Mike,

i tried writing a review, but i don't understand what's going on here.
Can you add some comments to the code?

cheers,
Janek

http://codereview.appspot.com/4810072/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Added \compoundMeter function to NR (issue4837050)

2011-08-05 Thread lemniskata . bernoullego



http://codereview.appspot.com/4837050/diff/9001/Documentation/music-glossary.tely
File Documentation/music-glossary.tely (right):

http://codereview.appspot.com/4837050/diff/9001/Documentation/music-glossary.tely#newcode2114
Documentation/music-glossary.tely:2114: \compoundMeter #'((3 8) (2 8) (4
8))
Nice catch!

http://codereview.appspot.com/4837050/diff/9001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/4837050/diff/9001/Documentation/notation/rhythms.itely#newcode1554
Documentation/notation/rhythms.itely:1554: multiplied by 2/3 -- as 2/3 *
9/8 = 3/4 -- and in the third staff, the
either -- as ... -- or (as ...) is fine imo.

http://codereview.appspot.com/4837050/diff/9001/Documentation/notation/rhythms.itely#newcode1642
Documentation/notation/rhythms.itely:1642: single list of numbers, where
each number in the @code{#'@var{(list)}}
After some consideration i think that we should abandon explaining the
fact that \compoundMeter #'(2 2 2 8) == \compoundMeter #'((2 2 2 8)).
Typing two braces more won't hurt anyone, while explaining how it works
seems to be either confusing ("was it a list of numbers or a list of
lists?") or too long.

http://codereview.appspot.com/4837050/diff/9001/Documentation/notation/rhythms.itely#newcode1644
Documentation/notation/rhythms.itely:1644: listed is the
@q{denominator}.
I find it a bit confusing: is each number a numerator or not?
I'd write it like that: the last number in the list is the denominator,
remaining numbers are written in numerator.
I find the description used in the regtest
(http://lilypond.org/doc/v2.15/input/regression/58/lily-ae87e9d8.ly) the
most clear and precise, but it uses mathematical terminology (fraction,
summand) which will probably cause problems for some users :(

http://codereview.appspot.com/4837050/diff/9001/Documentation/notation/rhythms.itely#newcode1653
Documentation/notation/rhythms.itely:1653: More complex meters can be
constructed using a @q{list of lists}.
I'd write "more lists as arguments" instead of "a @q{list of lists}"

http://codereview.appspot.com/4837050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: print transposed guitar chords on piano sheets (issue4626094)

2011-08-03 Thread lemniskata . bernoullego


This patch is obsolete.  Current patch is here
http://codereview.appspot.com/4800051/ and it is compatible with fixcc.
My bad... I should've closed this issue and sent a note.

http://codereview.appspot.com/4626094/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: modifying default behaviour of tremolo slashes (issue4636081)

2011-08-03 Thread lemniskata . bernoullego


Oh no!  I hoped to get it on this countdown.
A version compatible with fixcc uploaded.

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: Added \compoundMeter function to NR (issue4837050)

2011-08-02 Thread lemniskata . bernoullego


I think the \compoundMeter description should be more detailed.


http://codereview.appspot.com/4837050/diff/1/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

http://codereview.appspot.com/4837050/diff/1/Documentation/notation/rhythms.itely#newcode1555
Documentation/notation/rhythms.itely:1555: shown durations are
multiplied by 3/5 (3/5 * 10/8 = 3/4).  It may be
I think these parentheses might be confusing.  One can think that the
contents of the parentheses are to be multiplied by the fraction before
it.

http://codereview.appspot.com/4837050/diff/1/Documentation/notation/rhythms.itely#newcode1638
Documentation/notation/rhythms.itely:1638: \compoundMeter #'@var{(list
of numbers)}
the argument of \compoundMeter is a list of lists, not a list of
numbers.  List of numbers = #'(number number number ...) , list of lists
= #'( (list) (list) (list) ...) where each (list) is something like
(number number number ...).
I think that the description should be overall more verbose, as this is
easy to be misunderstood.  See my comment in tracker issue
(http://code.google.com/p/lilypond/issues/detail?id=1776) for a detailed
explanation.

http://codereview.appspot.com/4837050/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

2011-07-31 Thread lemniskata . bernoullego


New patch set uploaded (adding a regtest).

2011/8/1 Wols Lists :

Regression test attached. I've looked at the other regression tests

and

tried to make it similar.


Great!


http://codereview.appspot.com/4800051/diff/14003/input/regression/chord-capo.ly
File input/regression/chord-capo.ly (right):

http://codereview.appspot.com/4800051/diff/14003/input/regression/chord-capo.ly#newcode4
input/regression/chord-capo.ly:4: texidoc="Properties capoPitch,
capoVertical: display chordnames, suitably
trailing whitespace here

http://codereview.appspot.com/4800051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

2011-07-31 Thread lemniskata . bernoullego


New patch uploaded. Passes regtests made from scratch.

http://codereview.appspot.com/4800051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

2011-07-30 Thread lemniskata . bernoullego


New patch from Wol uploaded.

http://codereview.appspot.com/4800051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: modifying default behaviour of tremolo slashes (issue4636081)

2011-07-29 Thread lemniskata . bernoullego


Reinhold:
ok, replaced parallelogram with beam-like

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: modifying default behaviour of tremolo slashes (issue4636081)


New patch set uploaded.  Minor style change: slash shape that was named
"default" (which was confusing) is now named "parallelogram" (because
that's how it looks like).
If you don't like parallelograms ;) we can name it beam-like or sth.

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Ends of barlines are hidden in staff lines. (issue4809057)


Reviewers: hanwenn,

Message:

http://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01051.html
2011/7/27 Han-Wen Nienhuys :


Due to rounding, PDF viewers can err
the placement of the barline by a pixel.
[so that it looks like sticking out of staff]



You can make the problem disappear by



- hard coding the output to a certain resolution
- making the bar go to the middle of the staffline,
   rather than the outside.



both have disadvantages.


This patch does the second thing.  What disadvantages do you see besides
what happens when barline and staff have different colors?

cheers,
Janek

Description:
Ends of barlines are hidden in staff lines.

Barlines are made a little shorter, so that the end of the barline
doesn't touch
the outer edge of staff line - it ends in the middle of staff line now.
This prevets artifacts in pdf viewing and printing.

Please review this at http://codereview.appspot.com/4809057/

Affected files:
  M lily/bar-line.cc
  M lily/include/staff-symbol-referencer.hh
  M lily/staff-symbol-referencer.cc


Index: lily/bar-line.cc
diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index  
a2d6588726bb823c03075ca65dc35b663ecffaa3..64ca4d0dbd7bbb80f8c8aa87e4ec8966e2d7e58d  
100644

--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -34,8 +34,22 @@ Bar_line::calc_bar_extent (SCM smob)
   Interval result;
   Grob *me = unsmob_grob (smob);
   if (Grob *staff = Staff_symbol_referencer::get_staff_symbol (me))
-result = staff->extent (staff, Y_AXIS);
-
+{
+  result = staff->extent (staff, Y_AXIS);
+
+  /* Due to rounding problems, barlines extending to the outermost  
edges

+ of the staff lines appear wrongly in on-screen display
+ (and, to a lesser extent, in print) - they stick out a pixel.
+ The solution is to extend barlines only to the middle
+ of the staff line - unless they have different colors,
+ when it would be undesirable.
+  */
+  SCM bar_line_color = me->get_property ("color");
+  SCM staff_color = Staff_symbol_referencer::color (me);
+  if (bar_line_color == staff_color)
+   result *= (1 - 0.5 * (Staff_symbol_referencer::line_thickness (me) /
+ Staff_symbol_referencer::staff_radius (me)));
+}
   return ly_interval2scm (result);
 }

Index: lily/include/staff-symbol-referencer.hh
diff --git a/lily/include/staff-symbol-referencer.hh  
b/lily/include/staff-symbol-referencer.hh
index  
ed6156c62c78b1a1acae8423c1906d6e10cf8226..39889f2388f7a0111bad4c8d41207a5c26444641  
100644

--- a/lily/include/staff-symbol-referencer.hh
+++ b/lily/include/staff-symbol-referencer.hh
@@ -40,6 +40,7 @@ public:
  typeface. ie. leading is vertical space.
   */
   static Real line_thickness (Grob *);
+  static SCM color (Grob *);
   static Real staff_space (Grob *);
   static Grob *get_staff_symbol (Grob *);
   static bool on_line (Grob *, int);
Index: lily/staff-symbol-referencer.cc
diff --git a/lily/staff-symbol-referencer.cc  
b/lily/staff-symbol-referencer.cc
index  
2939e0c0614fdb035fe5a62409c4708f7bbf03ee..fcf7c3b76a900ce0bbd33fd4e08da8f3c1fcca6c  
100644

--- a/lily/staff-symbol-referencer.cc
+++ b/lily/staff-symbol-referencer.cc
@@ -63,6 +63,15 @@ Staff_symbol_referencer::staff_space (Grob *me)
   return 1.0;
 }

+SCM
+Staff_symbol_referencer::color (Grob *me)
+{
+  Grob *st = get_staff_symbol (me);
+  if (st)
+return st->get_property ("color");
+  return ly_symbol2scm ("black");
+}
+
 Real
 Staff_symbol_referencer::line_thickness (Grob *me)
 {



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Remove special case in staff-spacing (issue4188051)


Keith,

I am so sorry - you've sent me this patch ages ago and i forgot about
it! :(
I've checked regtests to see how it works and it's great!!
However, i cannot write any meaningful review, because i don't
understand what's going on here at all :(  Could you add some comments
for rookies like me (the more, the better)?

Thanks!!
Janek


http://codereview.appspot.com/4188051/diff/17001/scm/define-grobs.scm
File scm/define-grobs.scm (left):

http://codereview.appspot.com/4188051/diff/17001/scm/define-grobs.scm#oldcode2237
scm/define-grobs.scm:2237: (extra-spacing-height . (-1.0 . 1.0))
Why this disappeared?

http://codereview.appspot.com/4188051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: font: change breve vertical lines (issue4748044)


A pdf proof file is attached to tracker issue
http://code.google.com/p/lilypond/issues/detail?id=1767  The gap in
smallest font sizes was reduced according to Bertrand's suggestion, and
the line height was increased just a bit according to my friend's
suggestion.
I don't feel strong about these changes; for me both this version and
previous version is good enough (and definately better than current
Lily).


http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf
File mf/feta-noteheads.mf (right):

http://codereview.appspot.com/4748044/diff/1/mf/feta-noteheads.mf#newcode181
mf/feta-noteheads.mf:181: % when there is an interval of fourth.
On 2011/07/27 05:03:15, lemzwerg wrote:

Wouldn't it be simpler to explicitly specify the line length instead

of using

such a complicated algorithm?  I mean a global variable to be added to

the

various feta-noteheadsXX.mf files.  I know that none of the existing

size driver

files contain such a variable except the standard assignment of

`design_size',

but this shouldn't stop you to add something since it would be the

logical place

to add.  Cf. similar control files in other MF fonts like TeX's

Computer Modern,

which are full of such meta-variables.


Aww, i was so proud of this code...
Frankly, i don't think we will gain anything from defining a global
value.  The algorithm i wrote is a bit complicated, but i thinks is
easier to understand than what you suggest (if i understood your
suggestion correctly).  It keeps things in one place instead of values
flying all around (at least that's how i see it).

http://codereview.appspot.com/4748044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: changing shape of the G clef (issue4664070)

2011-07-27 Thread lemniskata . bernoullego


Going back to replacing the clef only.  Old glyph is no longer in the
patch, we may discuss it separately.

http://codereview.appspot.com/4664070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

2011-07-25 Thread lemniskata . bernoullego


Uploaded Carl's fix, everything works now!
I'm making from scratch and will run regtests.

http://codereview.appspot.com/4800051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modify chord-name-engraver to call capo-handler (issue4800051)

2011-07-25 Thread lemniskata . bernoullego


New patch from Wol uploaded.  According to Carl, it addresses previous
concerns; we only have a problem with Scheme syntax left.
(don't run regtests on this yet)

http://codereview.appspot.com/4800051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Modify chord-name-engraver to call capo-handler (issue4800051)

2011-07-25 Thread lemniskata . bernoullego


Reviewers: carl.d.sorensen_gmail.com,

Description:
Modify chord-name-engraver to call capo-handler


Add capo properties to define-context-properties


Add capo-handler function for guitar chords

Please review this at http://codereview.appspot.com/4800051/

Affected files:
  M lily/chord-name-engraver.cc
  M scm/chord-name.scm
  M scm/define-context-properties.scm


Index: lily/chord-name-engraver.cc
diff --git a/lily/chord-name-engraver.cc b/lily/chord-name-engraver.cc
index  
d0ced5a395f836e99fe57970185e26793b52612f..2442cdbb95835a3f5ebb826b5507dcce5f2978d9  
100644

--- a/lily/chord-name-engraver.cc
+++ b/lily/chord-name-engraver.cc
@@ -124,8 +124,8 @@ Chord_name_engraver::process_music ()

   pitches = scm_sort_list (pitches, Pitch::less_p_proc);

-  SCM name_proc = get_property ("chordNameFunction");
-  markup = scm_call_4 (name_proc, pitches, bass, inversion,
+  SCM capo_proc = ly_lily_module_constant ("capo-handler");
+  markup = scm_call_4 (capo_proc, pitches, bass, inversion,
   context ()->self_scm ());
 }
   /*
Index: scm/chord-name.scm
diff --git a/scm/chord-name.scm b/scm/chord-name.scm
index  
79b018992ac34650c879c3c16dfb45f29b914da5..6910044182d09673493b787d19c5125269f10a8e  
100644

--- a/scm/chord-name.scm
+++ b/scm/chord-name.scm
@@ -170,3 +170,27 @@ FOOBAR-MARKUP) if OMIT-ROOT is given and non-false.
 (alist (map chord-to-exception-entry elts)))
 (filter (lambda (x) (cdr x)) alist)))

+(define-public (capo-handler pitches bass inversion context)
+  (let (chord-function (ly:context-property context 'chordNameFunction #f))
+(capo-pitch (ly:context-property context 'capoPitch #f))
+(if  (not (capo-pitch)) ;; if there's no capo pitch or  
no chord
+  (chord-function pitches bass inversion context) ;; call the  
chordNameFunction as of old
+  (let ((new-pitches   ;; else  
transpose the pitches and do the chord twice

+(map (lambda (p)
+  (ly:pitch-transpose p capo-pitch))
+  pitches))
+  (new-bass
+(and (ly:pitch? bass)
+  (ly:pitch-transpose bass capo-pitch)))
+  (new-inversion
+(and (ly:pitch? inversion)
+  (ly:pitch-transpose inversion
+  capo-pitch)))
+
+  (capo-markup (make-parenthesize-markup (chord-function  
new-pitches new-bass new-inversion context)))

+  (markup (chord-function pitches bass  inversion context))
+
+  (capo-vertical (ly:context-property context 'capoVertical #f))
+  (if (capo-vertical)
+(make-column-markup (list markup capo-markup))
+(make-line-markup (list markup (make-hspace-markup 1)  
capo-markup

Index: scm/define-context-properties.scm
diff --git a/scm/define-context-properties.scm  
b/scm/define-context-properties.scm
index  
dab5211f14372444171626f23fb0ef3120175ee8..d17f72fa2c687b7dc5aff148e8d7c906a9b48c25  
100644

--- a/scm/define-context-properties.scm
+++ b/scm/define-context-properties.scm
@@ -135,6 +135,8 @@ that normally end on beats.")
  (beatStructure ,list? "List of @code{baseMoment}s that are combined
 to make beats.")

+ (capoPitch ,ly:pitch? "The pitch to transpose chords down by when  
using the capo.")
+ (capoVertical ,boolean? "Whether to display actual and transposed  
pitches above each other or not.")

  (chordChanges ,boolean? "Only show changes in chords scheme?")
  (chordNameExceptions ,list? "An alist of chord exceptions.
 Contains @code{(@var{chord} . @var{markup})} entries.")



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: modifying default behaviour of tremolo slashes (issue4636081)

2011-07-24 Thread lemniskata . bernoullego


Joe: redundant lines removed.

Interesting thing happens when i compare regtests: i see a difference in
part-combine-tuplet-end.ly, which is completely unrelated to tremolos.
Even funnier, my branch compiled this test better than master...
Perhaps i should've built from scratch.

BTW, should i add a regtest to this?

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Produces better error messages when programmers forget to document a property. (issue4801045)

2011-07-23 Thread lemniskata . bernoullego


On 2011/07/20 12:47:56, MikeSol wrote:

I've needed something like this for a long time - lemme know what you

think!

I don't understand how it works, but from what i suppose it's results
will be very nice!

thanks,
Janek

http://codereview.appspot.com/4801045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: modifying default behaviour of tremolo slashes (issue4636081)

2011-07-23 Thread lemniskata . bernoullego


New patch set uploaded.  Current Lily default behaviour is kept as
default now.


http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc
File lily/stem-tremolo.cc (right):

http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc#newcode42
lily/stem-tremolo.cc:42: style = ly_symbol2scm ("constant");
On 2011/07/21 08:39:53, joeneeman wrote:

You can remove these two lines and use
style == ly_symbol2scm ("varying")
below


Done.

http://codereview.appspot.com/4636081/diff/10001/lily/stem-tremolo.cc#newcode93
lily/stem-tremolo.cc:93: style = ly_symbol2scm ("constant");
On 2011/07/21 08:39:53, joeneeman wrote:

These two lines are redundant.


Isn't their purpose to guard against undefined (empty) style property?

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: changing shape of the G clef (issue4664070)

2011-07-23 Thread lemniskata . bernoullego


I guess this fixes the problem with "old" style for non-G clefs.


http://codereview.appspot.com/4664070/diff/8001/lily/clef.cc
File lily/clef.cc (right):

http://codereview.appspot.com/4664070/diff/8001/lily/clef.cc#newcode51
lily/clef.cc:51: str = str + "_" + clef_style;
On 2011/07/17 21:09:45, Neil Puttock wrote:

you can't add clef_style unless you know glyph == "clefs.G"


Done.

http://codereview.appspot.com/4664070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: CG: describe new C++ formatting (GOP-PROP 3) (issue4760056)

2011-07-19 Thread lemniskata . bernoullego



http://codereview.appspot.com/4760056/diff/1/Documentation/contributor/programming-work.itexi
File Documentation/contributor/programming-work.itexi (right):

http://codereview.appspot.com/4760056/diff/1/Documentation/contributor/programming-work.itexi#newcode334
Documentation/contributor/programming-work.itexi:334: for normal
contributors or developers/
/ is a typo?

http://codereview.appspot.com/4760056/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Creates callback for stem-begin-position. (issue4752048)

2011-07-18 Thread lemniskata . bernoullego


My "review" will be a bit non-standard (as i'm still a rookie
programmer): i understand what's going on here, so it's probably good :)

http://codereview.appspot.com/4752048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

font: change breve vertical lines (issue4748044)

2011-07-17 Thread lemniskata . bernoullego


Reviewers: ,

Message:
Hi,

breve glyphs in Feta font need modification.

What is bad now: breves lying between the stafflines form a
hard-to-recognize clump, partly because the corners (marked in orange
here:
http://lilypond.googlecode.com/issues/attachment?aid=1767000&name=breve+dimensions.png&token=be66e1b143abc7ec3429340cd32103e3&inline=1)
are too small.  Smaller font sizes and ledger lines intensify this.
Breves lying on stafflines are also not good - too stumpy.
Try printing this for example:
http://lilypond.googlecode.com/issues/attachment?aid=1767002&name=Miserere+current+Lily.pdf&token=63749404ea6a8c2d3447fb4080494627

Here is my homework :)
http://lilypond.googlecode.com/issues/attachment?aid=1767001&name=breve+examples.png&token=3c9237933bb9a936015f36fed35e1936&inline=1

As we can see:
- there is some variation
- majority of breves have lines higher than notehead
- if line height is similar to notehead height, fudge value is negative
or at least 0

Therefore i suggest to:
- make vertical lines higher
- decrease the fudge, especially in small font designs
- increase the gap for smaller design sizes
- decrease the line width in double-lined breves (the glyph looks less
fat then)

Tracker issue: http://code.google.com/p/lilypond/issues/detail?id=1767
I attached a bunch of test files showing differencies to the tracker
issue.  If possible, try printing them instead of watching on-screen,
because this issue is quite specific to printed material.

How do you like it?

PS i'll have to cut down on issue descriptions and example researchig...
It takes much more time than writing a patch itself :(

Description:
font: change breve vertical lines

Put breve vertical lines farther apart
and make them longer to increase readability.

Please review this at http://codereview.appspot.com/4748044/

Affected files:
  M mf/feta-noteheads.mf


Index: mf/feta-noteheads.mf
diff --git a/mf/feta-noteheads.mf b/mf/feta-noteheads.mf
index  
c72522072195d2b9751158e12cd0014a333294c2..e574cc1cf52ff16e456031f634e40b4fab1d7cbd  
100644

--- a/mf/feta-noteheads.mf
+++ b/mf/feta-noteheads.mf
@@ -157,24 +157,36 @@ if test > 0:
 fi;


-%
-% dimensions aren't entirely right.
-%
-def draw_brevis (expr linecount) =
+def draw_brevis (expr linecount, line_thickness_multiplier) =
save stemthick, fudge;

-   stemthick# = 2 stafflinethickness#;
+   stemthick# = line_thickness_multiplier * 2 * stafflinethickness#;
define_whole_blacker_pixels (stemthick);

-   fudge = hround (blot_diameter / 2);
+   % Breves of smaller design sizes should have their lines
+   % farther apart (the overlap should be smaller).
+   fudge = hround (blot_diameter *
+   min (max (-0.3, (0.8 - (20 / (design_size + 4)) + .1 
linecount)), 0.3));

draw_outside_ellipse (1.80, 0, 0.707, 0);
undraw_inside_ellipse (1.30, 125, 0.68, 2 stafflinethickness#);

pickup pencircle scaled stemthick;

-   bot y1 = -d;
-   top y2 = h;
+   % Breves of smaller design sizes should have their lines longer.
+   line_length := min (max (0.7, (31/30 - (design_size / 60))), 0.82);
+
+   % Line lengths between 0.72 and 0.77 are not nice
+   % because they are neither separate nor connected
+   % when there is an interval of fourth.
+   if line_length < 0.75:
+   quanted_line_length := min (0.72, line_length);
+   else:
+   quanted_line_length := max (0.77, line_length);
+   fi;
+
+   bot y1 = -quanted_line_length * staff_space;
+   top y2 = quanted_line_length * staff_space;
rt x1 - fudge = 0;
x1 = x2;

@@ -183,17 +195,22 @@ def draw_brevis (expr linecount) =
y4 = y2;
y3 = y1;

+   % Breves of smaller design sizes should have their lines
+   % farther apart.
+   line_distance := (1.95 - 0.008 * design_size) * stemthick;
for i := 0 step 1 until linecount - 1:
-   draw_gridline (z1 - (1.5 * i * stemthick, 0),
-  z2 - (1.5 * i * stemthick, 0), stemthick);
-   draw_gridline (z3 + (1.5 * i * stemthick, 0),
-  z4 + (1.5 * i * stemthick, 0), stemthick);
+   draw_gridline (z1 - (i * line_distance, 0),
+  z2 - (i * line_distance, 0),
+  stemthick);
+   draw_gridline (z3 + (i * line_distance, 0),
+  z4 + (i * line_distance, 0),
+  stemthick);
endfor;
 enddef;


 fet_beginchar ("Brevis notehead", "sM1");
-   draw_brevis (1);
+   draw_brevis (1, 1);

draw_staff (-2, 2, 0);
 fet_endchar;
@@ -201,7 +218,7 @@ fet_endchar;

 if test > 0:
fet_beginchar ("Brevis notehead", "sM1");
-   draw_brevis(1);
+   draw_brevis(1, 1);

draw_staff (-2, 2, 0.5);
fet_endchar;
@@ -209,7 +226,7 @@ fi;


 fet_beginchar ("Double

Re: modifying default behaviour of tremolo slashes (issue4636081)

2011-07-17 Thread lemniskata . bernoullego


Finally - new patch set uploaded.
Now it's possible to easily switch between different tremolo behaviours.
'Style' property is no longer used to choose between rectangular and
beam-like slashes - this is now done using 'shape' property.
'Style' property now influences both 'shape' and 'slope' of the slashes:
- style=constant produces beam-like slashes with slope .4 in case of
downstem flagged notes and slope .25 in all other cases,
- style=varying is equal to current default behaviour.

It's possible to choose a combination of those by setting both 'style'
and 'shape' properties.

Pdf demonstrating new behaviour:
http://lilypond.googlecode.com/issues/attachment?aid=17350003001&name=tremolo+new.pdf&token=4f500aee754e0419a28c61dc1a2abf6d

Please review. Suggestions on value names are most welcome!

http://codereview.appspot.com/4636081/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: changing shape of the G clef (issue4664070)

2011-07-16 Thread lemniskata . bernoullego


New patch set uploaded.

\override Staff.Clef #'style = #'old  tells Lily to use previous clef
glyph instead of my new clef.
(dedicated to James)

http://codereview.appspot.com/4664070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add hihat halfopen glyph to font (issue4714043)

2011-07-14 Thread lemniskata . bernoullego


The slash looks too long to me, especially when compared to halfopen
(unstopped).  I'd change factor to

factor := 11/10 * sqrt(1 + 25/16);
or maybe even
factor := 4/4 * sqrt(1 + 25/16);

otherwise LGTM.
thanks,
Janek

http://codereview.appspot.com/4714043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Move \RemoveEmptyStaves to new file for context modifications (issue #1760) (issue4664076)

2011-07-13 Thread lemniskata . bernoullego


The change looks pretty straightforward, but i don't understand why
simply moving RemoveEmptyStaff definition changes anything :(

cheers,
Janek

http://codereview.appspot.com/4664076/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: changing shape of the G clef (issue4664070)

2011-07-11 Thread lemniskata . bernoullego


New patch set uploaded - the suggested clef is a bit higher now.  Images
can be found in tracker issue:
http://code.google.com/p/lilypond/issues/detail?id=1752

http://codereview.appspot.com/4664070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Flag functions instead of defining glyphs directly (issue4625067)

2011-07-11 Thread lemniskata . bernoullego


This was just pushed by Mike.
I close the issue.

thanks,
Janek

http://codereview.appspot.com/4625067/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an example of minimal example (issue4636082)

2011-07-10 Thread lemniskata . bernoullego


New patch set uploaded.
I think that everything works now.

cheers,
Janek


http://codereview.appspot.com/4636082/diff/10003/Documentation/css/lilypond-website.css
File Documentation/css/lilypond-website.css (right):

http://codereview.appspot.com/4636082/diff/10003/Documentation/css/lilypond-website.css#newcode897
Documentation/css/lilypond-website.css:897: text-align: left;
I've also pondered at adding

  width: 96%;
  padding: 1em;
  border: solid #b1d281;
  border-width: 1px 1px 1px 5px;

to make these similar to code examples in manuals, but i decided it
would change too much.

http://codereview.appspot.com/4636082/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Small pitch bends correct and tested. (issue4654063)

2011-07-10 Thread lemniskata . bernoullego


Graham,

I'm worried that i don't hear anything from you since 2 weeks!
Do you experience any problems with fixing code style issues pointed to
by Neil?
If you are very busy, i can fix them myself, but i'd prefer that you fix
them and send me the collection of all patches, up-to-date (this will
minimize the risk of messing something up).  If you encounter any
problems with git, i'll gladly help.

cheers,
Janek

On 2011/06/26 13:13:50, Neil Puttock wrote:

LGTM.



http://codereview.appspot.com/4654063/diff/1/lily/midi-item.cc
File lily/midi-item.cc (right):



http://codereview.appspot.com/4654063/diff/1/lily/midi-item.cc#newcode202

lily/midi-item.cc:202: + audio_->transposing_.tone_pitch ()) *

Rational (2));

indent:



((audio_
   + audio



http://codereview.appspot.com/4654063/diff/1/lily/midi-item.cc#newcode203

lily/midi-item.cc:203: return (tune > 0)? int (tune + 0.5): int(tune -

0.5);

int (rint (tune));



http://codereview.appspot.com/4654063/diff/1/lily/midi-item.cc#newcode216

lily/midi-item.cc:216: finetune = PITCH_WHEEL_CENTER +

get_fine_tuning();

get_fine_tuning ();




http://codereview.appspot.com/4654063/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Separate flags into their own sub-font. (issue4654084)

2011-07-09 Thread lemniskata . bernoullego


Carl,

are there any problems?  The countdown is over but i don't see it
pushed.

cheers,
Janek

http://codereview.appspot.com/4654084/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an example of minimal example (issue4636082)

2011-07-09 Thread lemniskata . bernoullego


New patch set uploaded.


http://codereview.appspot.com/4636082/diff/13003/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

http://codereview.appspot.com/4636082/diff/13003/Documentation/web/community.itexi#newcode320
Documentation/web/community.itexi:320: or @code{%@{ @dots{} %@}})}
sections of your file first.  If you
On 2011/07/09 07:51:13, Graham Percival wrote:

remove the word "first".  It doesn't really add anything to the

sentence.

Hmm, ok.

http://codereview.appspot.com/4636082/diff/13003/Documentation/web/community.itexi#newcode322
Documentation/web/community.itexi:322: then remove the
commented-material completely.
On 2011/07/09 07:51:13, Graham Percival wrote:

What does the word "completely" add to this sentence?  I mean, how do

we expect

users to remove commented-material partly?


Done.

http://codereview.appspot.com/4636082/diff/13003/Documentation/web/community.itexi#newcode333
Documentation/web/community.itexi:333: If possible, attach an image
showing what do you want to achieve
On 2011/07/09 07:51:13, Graham Percival wrote:

Change this:



Optionally, attach an image showing the desired graphical output.


"desired graphical output" is very nice and elegant, but i wouldn't
change "if possible" to "optionally".  IMO graphical samples are *very*
useful and make answering a lot easier and faster, so we should
encourage them as much as possible.

http://codereview.appspot.com/4636082/diff/13003/Documentation/web/community.itexi#newcode346
Documentation/web/community.itexi:346: @example
On 2011/07/09 07:51:13, Graham Percival wrote:

This needs to be flush left, not centered.


Yes. As i wrote
"I have a problem with the box at the bottom: code examples are
center-aligned, not left-aligned.  I didn't found any example of how
it's done in our manuals; i searched texinfo documentation and found
@flushleft, but it didn't work... How should i do this?"

http://codereview.appspot.com/4636082/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

changing shape of the G clef (issue4664070)

2011-07-08 Thread lemniskata . bernoullego


Reviewers: Reinhold, james.lowe_datacore.com, x.scheuer_gmail.com,

Message:
A tip to speed up work if you try to modify clef shape: use this script
to generate a dvi preview of glyphs (no need to run make, and it also
shows metafont control points):
#!/bin/bash
mf '\mode:=proof; input feta20'
 gftodvi feta20.2602gf \
 && mv feta20.dvi feta20new.proof.dvi

Description:
changing shape of the G clef

makes upper loop smaller,
bottom crook sticks less,
vertical line is more evenly curved.
Also the upper loop is slightly bigger
in reduced version of the clef than
in the regular version, to fit stafflines well.

Please review this at http://codereview.appspot.com/4664070/

Affected files:
  M mf/feta-clefs.mf


Index: mf/feta-clefs.mf
diff --git a/mf/feta-clefs.mf b/mf/feta-clefs.mf
index  
4522395cf6e08f20072b30aec272a10802ef90a7..8976fa1aabcd4dd2674a5062cd04414c82c283ae  
100644

--- a/mf/feta-clefs.mf
+++ b/mf/feta-clefs.mf
@@ -317,6 +317,11 @@ def draw_gclef (expr reduction) =
reduced_ss# = staff_space# * reduction;
define_pixels (reduced_ss);

+   % G clef has now a smaller upper loop than it used to have.
+   % Too small loop in reduced clef (G_change) interacts badly
+   % with stafflines, so we make reduced clef's loop a bit bigger.
+   reduced_loop_correction := min (max (0.925, (0.55 + 0.5 * reduction)), 
1);
+
thinness = 0.095 staff_space + 0.75 linethickness;
downstroke_dir = unitvector (14, -75);
downstroke_angle = angle downstroke_dir;
@@ -333,7 +338,7 @@ def draw_gclef (expr reduction) =
thinnib = thinness;

set_char_box (0, 1.71 * breapth_factor * reduced_ss#,
- 2.6 * reduced_ss#, 5 * reduced_ss#);
+ 2.435 * reduced_ss#, 4.6 * reduced_ss# / 
reduced_loop_correction);

center := (breapth_factor * reduced_ss, 0);

@@ -356,32 +361,32 @@ def draw_gclef (expr reduction) =
y5r = .37 reduced_ss + ypart center;
penpos5 (thickness, upward_swoosh_angle);

-   z6 = center + whatever * downstroke_dir;
-   y6 = ypart center + 2 reduced_ss;
+   z6 = center + whatever * downstroke_dir - (0.033, 0) * reduced_ss;
+   y6 = ypart center + 1.9 reduced_ss / reduced_loop_correction;
% penpos6 is computed later

-   z7l - z6 = whatever * (z5 - z6) ;
-   y7l = 3.5 reduced_ss;
+   z7l - z6 = whatever * (z5 - z6);
+   y7l = 3.25 reduced_ss / reduced_loop_correction;
penpos7 (thickness, upward_swoosh_angle);

-   x9 = .7 [x10, x7r];
-   top y9l = 5 reduced_ss;
-   penpos9 (1.45 thickness, -70);
+   x9 = .8 [x10, x7r];
+   top y9l = 4.6 reduced_ss / reduced_loop_correction;
+   penpos9 (1.45 thickness, -75);

-   x11 - x13r = 1.5 reduced_ss + 0.5 thinnib;
-   y11 = ypart center - 47/28 reduced_ss;
-   y12 = ypart center - 71/28 reduced_ss;
+   x11 - x13r = 1.42 * reduced_ss + 0.5 thinnib;
+   y11 = ypart center - 43/28 reduced_ss;
+   y12 = ypart center - 66/28 reduced_ss;
y13 = .48 [y12, y4r];
x12r = xpart (.45 [z13r, z11] + .75 reduced_ss * downstroke_dir);

 %  z10 = center + whatever * dir (downstroke_angle - 1.5);
-   x10 = x6 - 2 thinnib;
-   y10 = ypart center + 3.5 reduced_ss;
+   x10 = x6 - 1.65 thinnib * reduction;
+   y10 = ypart center + 3.15 reduced_ss / reduced_loop_correction;
y10l - y10r = 1.0 thickness;
z10r - z10l = .7 thinnib * dir (downstroke_angle + 90)
  + whatever * downstroke_dir;
z10 = .5 [z10l, z10r];
-   z11 = center + whatever * downstroke_dir + (-0.05 reduced_ss, 0);
+   z11 = center + whatever * downstroke_dir + (0.02 reduced_ss, 0);

penpos11 (thinnib, start_angle + 90);
penpos12 (thinnib, bot_angle + 90);
@@ -403,7 +408,7 @@ def draw_gclef (expr reduction) =
z10' = point 0.3 of pat;
penpos10' (1.3 thinnib, angle (direction 0.3 of pat) + 50);

-   z11' = point 1.5 of pat;
+   z11' = point 1.5 of pat - (-0.033, 0.5) * reduced_ss;
penpos11' (thinnib, angle (direction 1.5 of pat) + 90);

z21l = z20l;



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an example of minimal example (issue4636082)

2011-07-08 Thread lemniskata . bernoullego


Reverted sentence about \version.

Ready to go?


http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi#newcode311
Documentation/web/community.itexi:311: Specify which release of LilyPond
you are using with a
On 2011/07/07 10:26:39, Graham Percival wrote:

On 2011/07/06 17:44:37, Janek Warchol wrote:
> Hmm, what about "Specify which "code{\version} of LilyPond you are

using."?


hmm, that's better, but it still feels a bit wordy.



I'm not feeling enthusiastic about this change.  Do we have any

evidence that

"include the \version number" is misunderstood?  If you can point to 3

emails to

bug-lilypond where people misunderstood this, then I'm fine with a

more wordy

explanation.


No, i don't have any proofs, it was just a guess.  Scrap it then.


(that said, adding the @code{} around \version is still a good change)


Done.

http://codereview.appspot.com/4636082/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: print transposed guitar chords on piano sheets (issue4626094)


New patch set uploaded.
Hmm, Wol, did you use some code formatting tool on a whole file? I see a
lot of style changes, and not all of them are for the good.

http://codereview.appspot.com/4626094/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an example of minimal example (issue4636082)



http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

http://codereview.appspot.com/4636082/diff/4002/Documentation/web/community.itexi#newcode311
Documentation/web/community.itexi:311: Specify which release of LilyPond
you are using with a
On 2011/07/06 14:36:39, Graham Percival wrote:

too wordy.  What was the problem with the original 4-word sentnce?

(ok, adding

@code{} would be good)


As i wrote to James, i thought it should be made clear that what matters
is the version of the actual binary, not what \version statement you are
using in your files. If someone was using 2.13.40 for some time, wrote a
file (with \version specified) for it, then installed 2.13.47 and
something broke, he may forgot to change version statement in his bug
report. (i don't update \version numbers in my files quite often
myself).
But i don't insist on this change.
Hmm, what about "Specify which "code{\version} of LilyPond you are
using."?

http://codereview.appspot.com/4636082/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: correcting note about rerunning regtests (issue4675048)



http://codereview.appspot.com/4675048/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/4675048/diff/1/Documentation/contributor/regressions.itexi#newcode276
Documentation/contributor/regressions.itexi:276: @code{make test-clean},
@code{make} and @code{make check} it without doing
On 2011/07/05 13:20:13, Reinhold wrote:

What's the difference to running make test-redo?


According to CG, make test-redo only checks regtests that had shown a
difference with baseline (for example you had had written a patch,
regtests had shown some unwanted differencies, so you wrote a fix and
want to check if this fix removes the regressions).

What i'm writing about should be useful if you have several unrelated
patches in separate branches and want to check regtests for all of them
(separately).

http://codereview.appspot.com/4675048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: print transposed guitar chords on piano sheets (issue4626094)


Some style nitpicks. I also think i found why it didn't work.


http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc
File lily/chord-name-engraver.cc (right):

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode126
lily/chord-name-engraver.cc:126: {
AFAIK when there is only one statement in if, we don't use braces. So it
should be
if (capo)
  capo_inversion = capo_transpose (p, capo_pitch);

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode135
lily/chord-name-engraver.cc:135: capo_bass = capo_transpose (p,
capo_pitch);
same as above

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode143
lily/chord-name-engraver.cc:143: capo_pitches = scm_cons (capo_transpose
(p, capo_pitch), capo_pitches);
same as above

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode166
lily/chord-name-engraver.cc:166: capo_pitches = scm_sort_list
(capo_pitches, Pitch::less_p_proc);
same as above

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode174
lily/chord-name-engraver.cc:174: capo_markup = scm_call_4 ( name_proc,
capo_pitches, capo_bass, capo_inversion,
same as above

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode187
lily/chord-name-engraver.cc:187: } else {
i think this should be

if (!capo)
  chord_name_->set_property ("text", markup);
else
{

http://codereview.appspot.com/4626094/diff/1/lily/chord-name-engraver.cc#newcode191
lily/chord-name-engraver.cc:191: SCM hspace_proc =
ly_lily_module_constant ("hspace_markup");
change line_markup to line-markup and hspace_markup to hspace-markup. I
think it will work then.

http://codereview.appspot.com/4626094/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

print transposed guitar chords on piano sheets (issue4626094)

2011-07-05 Thread lemniskata . bernoullego


Reviewers: antlists_youngman.org.uk, carl.d.sorensen_gmail.com,

Message:
Modify chord-name-engraver to print transposed guitar chords on piano
sheets
Add associated properties capoPitch and capoVertical to
define-context-properties

Description:
print transposed guitar chords on pia

Please review this at http://codereview.appspot.com/4626094/

Affected files:
  M lily/chord-name-engraver.cc
  M scm/define-context-properties.scm


Index: lily/chord-name-engraver.cc
diff --git a/lily/chord-name-engraver.cc b/lily/chord-name-engraver.cc
index  
d0ced5a395f836e99fe57970185e26793b52612f..5037825ca0149eb08d9e0150f0b45bc43334bf2e  
100644

--- a/lily/chord-name-engraver.cc
+++ b/lily/chord-name-engraver.cc
@@ -2,6 +2,7 @@
   This file is part of LilyPond, the GNU music typesetter.

   Copyright (C) 1998--2011 Jan Nieuwenhuizen 
+  Copyright (C) 2011 Anthony Youngman 

   LilyPond is free software: you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -43,11 +44,14 @@ protected:
   DECLARE_TRANSLATOR_LISTENER (note);
   DECLARE_TRANSLATOR_LISTENER (rest);
 private:
+  SCM capo_transpose( SCM, SCM) const;
+
   Item *chord_name_;
   vector notes_;

   SCM last_chord_;
   Stream_event *rest_event_;
+
 };

 void
@@ -76,6 +80,13 @@ Chord_name_engraver::process_music ()
   SCM inversion = SCM_EOL;
   SCM pitches = SCM_EOL;

+  SCM capo_markup;
+  SCM capo_bass = SCM_EOL;
+  SCM capo_inversion = SCM_EOL;
+  SCM capo_pitches = SCM_EOL;
+
+  bool capo = false;
+
   if (rest_event_)
 {
   SCM no_chord_markup = get_property ("noChordSymbol");
@@ -88,6 +99,17 @@ Chord_name_engraver::process_music ()
   if (!notes_.size ())
 return;

+  // This is set by "\set ChordNames.CapoPitch = #(ly:make-pitch 0 1  
1)" in the lily source file

+  // declare properties in define-context-properties.scm
+
+  SCM capo_pitch = get_property ( "capoPitch" );
+  bool capo = false;
+  if ( !(capo_pitch == SCM_EOL) )
+  {
+Pitch *cp = unsmob_pitch (capo_pitch);
+capo = (Pitch::compare ( *cp, Pitch() ) != 0);
+  }
+
   Stream_event *inversion_event = 0;
   for (vsize i = 0; i < notes_.size (); i++)
   {
@@ -100,11 +122,27 @@ Chord_name_engraver::process_music ()
 {
   inversion_event = n;
   inversion = p;
+  if (capo)
+  {
+capo_inversion = capo_transpose (p, capo_pitch);
+  }
 }
 else if (n->get_property ("bass") == SCM_BOOL_T)
+{
   bass = p;
+  if (capo)
+  {
+capo_bass = capo_transpose (p, capo_pitch);
+  }
+}
 else
+{
   pitches = scm_cons (p, pitches);
+  if (capo)
+  {
+capo_pitches = scm_cons (capo_transpose (p, capo_pitch),  
capo_pitches);

+  }
+}
   }

   if (inversion_event)
@@ -123,10 +161,19 @@ Chord_name_engraver::process_music ()
   }

   pitches = scm_sort_list (pitches, Pitch::less_p_proc);
-
+  if (capo)
+  {
+capo_pitches = scm_sort_list (capo_pitches, Pitch::less_p_proc);
+  }
+
   SCM name_proc = get_property ("chordNameFunction");
   markup = scm_call_4 (name_proc, pitches, bass, inversion,
   context ()->self_scm ());
+  if (capo)
+  {
+capo_markup = scm_call_4 ( name_proc, capo_pitches, capo_bass,  
capo_inversion,

+   context ()->self_scm ());
+  }
 }
   /*
 Ugh.
@@ -135,8 +182,25 @@ Chord_name_engraver::process_music ()

   chord_name_ = make_item ("ChordName",
   rest_event_ ? rest_event_->self_scm () : notes_[0]->self_scm ());
-  chord_name_->set_property ("text", markup);
-
+  if (!capo) {
+chord_name_->set_property ("text", markup);
+  } else {
+SCM capovertical = get_property ("capoVertical");
+SCM paren_proc = ly_lily_module_constant ("parenthesize-markup");
+SCM line_proc = ly_lily_module_constant ("line_markup");
+SCM hspace_proc = ly_lily_module_constant ("hspace_markup");
+
+SCM final_markup = scm_list_n (line_proc,
+   scm_list_3 (markup,
+   scm_list_2 (hspace_proc,
+
scm_from_int(1)),
+   scm_list_2 (paren_proc,  
capo_markup)),

+   SCM_UNDEFINED);
+
+chord_name_->set_property ("text", final_markup);
+  }
+
+
   SCM chord_changes = get_property("chordChanges");
   if (to_boolean (chord_changes) && scm_is_pair (last_chord_)
   && ly_is_equal (chord_as_scm, last_chord_))
@@ -145,6 +209,15 @@ Chord_name_engraver::process_music ()
   last_chord_ = chord_as_scm;
 }

+SCM
+Chord_name_engraver::capo_transpose (SCM scm_pitch, SCM capo_pitch) const
+{
+  Pitch *s_p = unsmob_pitch (scm_pitch);
+  Pitch *c_p = unsmob_pitch (cap

Re: an example of minimal example (issue4636082)

2011-07-05 Thread lemniskata . bernoullego

New patch set uploaded.

I have a problem with the box at the bottom: code examples are
center-aligned, not left-aligned. I didn't found any example of how
it's done in our manuals; i searched texinfo documentation and found
@flushleft, but it didn't work... How should i do this?

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode283
Documentation/web/community.itexi:283: The simpler the example is, the
quicker potential helpers can
On 2011/07/05 00:14:30, J_lowe wrote:

The tinier the example, the simpler it is and therefore, the

quicker...

I'm not sure if this is straightforward enough.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode287
Documentation/web/community.itexi:287: A simple example demonstrates
that you have put effort towards
On 2011/07/05 00:14:30, J_lowe wrote:

A tiny example also demonstrates to others on the email lists that

some kind of

effort has been taken to...

Too wordy imo.

[PS Are we talking 'simpler' or 'tinier' here? While I can see that

both work,

they are two different ideas and you are already moving away from

'tiny'. Can we

stick to tiny?]

Umm, i didn't touch anything here. I've only added that example part.
However, i agree that 'tiny' sounds better at the beginning of this
sentence.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode289
Documentation/web/community.itexi:289: input, it looks like they don't
care how if we help them or not.
"don't care how if we help them or not." Should 'how' be there? Looks
wrong to me...

solving the problem yourself. Whereas overly complex, large or

unedited examples

look like no effort has been made to try to attempt to solve the

problem

yourself and can discourage others from helping.

I think it's too wordy, and the repetition about solving the problem
yourself is not necessary.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode292
Documentation/web/community.itexi:292: Creating a tiny example forces
you to understand what is
On 2011/07/05 00:14:30, J_lowe wrote:

A tiny example can also help you to ...

I agree about the 'helping' part, but i wouldn't remove word 'creating'.
It's creating the tiny example that helps in understanding, not merely
having it.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode296
Documentation/web/community.itexi:296: insufficient understanding of
LilyPond, not an actual bug!
On 2011/07/05 00:14:30, J_lowe wrote:

...then the problem is usually due to a lack of understanding of how

the

LilyPond syntax works.

I prefer the original, it's grammatically simpler.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode305
Documentation/web/community.itexi:305: @subheading How do I create them?
On 2011/07/05 00:14:30, J_lowe wrote:

How to create them.

[we try to not personalise the text or talk in first/second person]

Good point, i agree.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode311
Documentation/web/community.itexi:311: Include the \version number.
On 2011/07/05 00:14:30, J_lowe wrote:

Include the LilyPond @code{\version} number you are using.

I changed it so that it should be plain that the version of the actual
binary matters, not what \version statement you are using in your files
(i don't update \version numbers in my files quite often myself).

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode314
Documentation/web/community.itexi:314: Make it small! Examples about
spacing or page layout might
On 2011/07/05 00:14:30, J_lowe wrote:

Keep it tiny! Examples about...

I'd leave word 'make' because creating a tiny ex is a process of
removing material.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode320
Documentation/web/community.itexi:320: or @code{%@{ @dots{} %@}})}
sections of your file. If you can
On 2011/07/05 00:14:30, J_lowe wrote:

..or @code{%@{ @dots{} %@}})} sections of your file first. If you

can...

Done.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode321
Documentation/web/community.itexi:321: comment something while still
demonstrating the main idea, then
On 2011/07/05 00:14:30, J_lowe wrote:

comment something out while ...

sounds awkward to me.

http://codereview.appspot.com/4636082/diff/10001/Documentation/web/community.itexi#newcode322
Documentation/web/community.itexi:322: remo

correcting note about rerunning regtests (issue4675048)

2011-07-05 Thread lemniskata . bernoullego


Reviewers: ,

Description:
correcting note about rerunning regtests

looks like it is necessary to make test-clean
if you want to check regtests on a new branch
without making test-baseline

Please review this at http://codereview.appspot.com/4675048/

Affected files:
  M Documentation/contributor/regressions.itexi


Index: Documentation/contributor/regressions.itexi
diff --git a/Documentation/contributor/regressions.itexi  
b/Documentation/contributor/regressions.itexi
index  
13c17651b9605d3f22b2c254e44c384a9f6bc8aa..7f4c9276169c22f9f52462b9fa95ee595df245c1  
100644

--- a/Documentation/contributor/regressions.itexi
+++ b/Documentation/contributor/regressions.itexi
@@ -273,8 +273,8 @@ unless git master changed. In other words, if you work  
with several branches

 and want to do regtests comparison for all of them, you can
 @code{make test-baseline} with git master, checkout some branch,
 @code{make} and @code{make check} it, then switch to another branch,
-@code{make} and @code{make check} it without doing @code{make  
test-baseline}

-again.}
+@code{make test-clean}, @code{make} and @code{make check} it without doing
+@code{make test-baseline} again.}


 @node Finding the cause of a regression



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an example of minimal example (issue4636082)


New patch set uploaded.

2011/7/4  :

I'm glad that you're working on it!  I'm just warning you that there
will be many nitpicks.


No problem.  If they aren't about code style, i can handle them :)


http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode275
Documentation/web/community.itexi:275: Is the code below a minimal
example?
On 2011/07/04 20:24:56, Graham Percival wrote:

This is way too long.  I spent a lot of time and effort making the

website as

minimal as possible to increase readability


I had this feeling too.


Hmm... I'd be ok with it if you put it in a box at the bottom of the

page.  I

actually can't believe that we don't have any examples on the Tiny

examples page

-- the only place to find something is on the Bug reports page!


Done (at least i hope that it's written correctly).

http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode277
Documentation/web/community.itexi:277: @lilypond
On 2011/07/04 20:24:56, Graham Percival wrote:

this won't compile; it would have to be @example instead, and that

will require

@{ @} escapes.


Umm.. is it right now?

http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode346
Documentation/web/community.itexi:346: using less than a single measure.
On 2011/07/04 20:24:56, Graham Percival wrote:

I prefer "only".  If somebody gets it down to 1 measure, we're not

going to

quibble about 2 beats vs. 4 beats.


Umm, James' original example was exactly one measure, and we condemned
it as being too long.

2011/7/4 James Harkins  wrote:

To me, one bar is tiny.


And after all, this wording doesn't force people to make examples less
then one measure at all costs.  It only suggests things.

http://codereview.appspot.com/4636082/diff/3/Documentation/web/community.itexi#newcode353
Documentation/web/community.itexi:353: 2 lines of code, and few exceed
10 lines.
On 2011/07/04 20:24:56, Graham Percival wrote:

Hmm.  I'm worried that this (combined with the next item) would make

the page

too wordy.  Leave it in there for the next draft, but I may complain

about it

later.


I moved it to the bottom box, how do you like it?

http://codereview.appspot.com/4636082/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Separate flags into their own sub-font. (issue4654084)


I've almost forgotten: i checked that Carl's patch set passes regtests.


http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):

http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1450
mf/feta-scripts.mf:1450: begingroup;
On 2011/07/04 20:48:45, Carl wrote:

On 2011/07/04 20:19:31, Janek Warchol wrote:
> You added this because every glyph should be in some group now?



No, the begingroup and endgroup define the scope over which the save

functions.

and the height, overshoot, and width that are used in this glyph

should be

limited to this glyph.


Ah, ok.

http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1452
mf/feta-scripts.mf:1452: height# := staff_space#;
On 2011/07/04 20:48:45, Carl wrote:

On 2011/07/04 20:19:31, Janek Warchol wrote:
> are the colons only a matter of style?



No.  The colon makes it an assignment.  Without the colon, it's an

equation that

becomes a constraint; eventually the equation is solved.



The intention here, AFAICS, is to have it be an assignment, so I made

it

explicit.


Yes, i'd say that too.

http://codereview.appspot.com/4654084/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: an example of minimal example (issue4636082)


On 2011/07/04 20:02:59, Carl wrote:

I like this, but I think it should have a little bit more information.



I don't think that the changes in the comments affect whether it is

minimal or

not -- perhaps the comments should be the same in both cases.


Imo it's more readable when the comment is briefer. Also the way in
wchich it divides the music is distracting for me.

thanks,
Janek

http://codereview.appspot.com/4636082/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds a warning for non-list fingeringOrientations settings. (issue4650070)


On 2011/07/04 13:14:55, Neil Puttock wrote:

Context_def::add_context_mod () is where the assignment takes place
(and you can see from set_property () how the type-checking is done).


Where is set_property defined?

cheers,
Janek

http://codereview.appspot.com/4650070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Separate flags into their own sub-font. (issue4654084)


LGTM!

Thank you, Carl!


http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf
File mf/feta-flags-generic.mf (right):

http://codereview.appspot.com/4654084/diff/42/mf/feta-flags-generic.mf#newcode4
mf/feta-flags-generic.mf:4: % Copyright (C) 1997--2011 Han-Wen Nienhuys

Shouldn't your name be here, Carl?

http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):

http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1450
mf/feta-scripts.mf:1450: begingroup;
You added this because every glyph should be in some group now?

http://codereview.appspot.com/4654084/diff/42/mf/feta-scripts.mf#newcode1452
mf/feta-scripts.mf:1452: height# := staff_space#;
are the colons only a matter of style?

http://codereview.appspot.com/4654084/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

an example of minimal example (issue4636082)


Reviewers: Graham Percival, james.lowe_datacore.com,

Message:
In response to
http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00060.html

Description:
an example of minimal example

for some people it's not clear enough how tiny
a tiny example should be. So i used a recently
discussed example to illustrate it.

Please review this at http://codereview.appspot.com/4636082/

Affected files:
  M Documentation/web/community.itexi


Index: Documentation/web/community.itexi
diff --git a/Documentation/web/community.itexi  
b/Documentation/web/community.itexi
index  
d6918d1fbc0504526444c58c5edac755016938ac..7f9551a5a8d1521c084904625025910cf1334d19  
100644

--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -270,7 +270,37 @@ guidelines for @ref{Bug reports}.}
 @divClass{column-center-top}
 @subheading What are @qq{Tiny examples}?

-A tiny example is an example from which nothing can be removed.
+A tiny example is an example from which @strong{nothing} can be removed.
+
+Is the code below a minimal example?
+
+@lilypond
+\version "2.14.1"
+\include "english.ly"
+
+\score {
+ \new Staff {
+   \key d \major
+   \numericTimeSignature
+   \time 2/4
+   16 8.
+   %% Here: the tie on the D's looks funny
+   %% Too tall? Left-hand endpoint is not aligned with the B tie?
+   ~
+   8 [  ]
+ }
+}
+@end lilypond
+
+Well, it is not very big, but a truly minimal example is here:
+
+@lilypond
+\version "2.14.1"
+{
+  % middle tie looks funny here:
+  8. ~ 8
+}
+@end lilypond
 @divEnd

 @divClass{column-left-bottom}



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

modifying default behaviour of tremolo slashes (issue4636081)


Reviewers: xratamacue_hotmail.com, reinhold_kainhofer.com,

Message:
Passes regtests.

Description:
modifying default behaviour of tremolo slashes

It turned out that tremolo slashes should have
quite constant slope (definately not depending
on beam slope), so i change that. I also changed
slash style so that it isn't rectangle in any
cases by dafault.

Please review this at http://codereview.appspot.com/4636081/

Affected files:
  M lily/stem-tremolo.cc


Index: lily/stem-tremolo.cc
diff --git a/lily/stem-tremolo.cc b/lily/stem-tremolo.cc
index  
4d1678889a63ee382a4a207bf5d31fd2424194f2..2163f08bca4737b1cd1fbdb631471d0b823e84e5  
100644

--- a/lily/stem-tremolo.cc
+++ b/lily/stem-tremolo.cc
@@ -37,6 +37,10 @@ Stem_tremolo::calc_slope (SCM smob)
   Grob *stem = unsmob_grob (me->get_object ("stem"));
   Spanner *beam = Stem::get_beam (stem);

+  /* We used to have tremolo slashes angled exactly like beams
+ (if the note had a beam), but it turned out
+ that it's not proper notation.
+
   if (beam)
 {
   Real dy = 0;
@@ -54,11 +58,13 @@ Stem_tremolo::calc_slope (SCM smob)
   return scm_from_double (dx ? dy / dx : 0);
 }
   else
-/* down stems with flags should have more sloped trems (helps avoid
-   flag/stem collisions without making the stem very long) */
-return scm_from_double (
-(Stem::duration_log (stem) >= 3 && get_grob_direction (stem) ==  
DOWN) ?

-  0.40 : 0.25);
+  */
+
+  /* down stems with flags should have more sloped trems (helps avoid
+ flag/stem collisions without making the stem very long) */
+  return scm_from_double (
+  (Stem::duration_log (stem) >= 3 && get_grob_direction (stem) ==  
DOWN) ?

+0.40 : 0.25);
 }

 MAKE_SCHEME_CALLBACK (Stem_tremolo, calc_width, 1)
@@ -79,6 +85,10 @@ MAKE_SCHEME_CALLBACK (Stem_tremolo, calc_style, 1)
 SCM
 Stem_tremolo::calc_style (SCM smob)
 {
+  /* We used to use rectangle tremolo style for beamed notes
+ and flagged upstem notes, but it looks like it shouldn't
+ be done that way.
+
   Grob *me = unsmob_grob (smob);
   Grob *stem = unsmob_grob (me->get_object ("stem"));
   Direction stemdir = get_grob_direction (stem);
@@ -86,6 +96,9 @@ Stem_tremolo::calc_style (SCM smob)
   bool flag = Stem::duration_log (stem) >= 3 && !beam;

   return ly_symbol2scm (((stemdir == UP && flag) ||  
beam) ? "rectangle" : "default");

+  */
+
+  return ly_symbol2scm ("default");
 }

 Real



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Braces redesigned (issue4581060)

2011-06-26 Thread lemniskata . bernoullego


Added to google tracker (sorry it's so late...), issue .
I understand that this Rietveld issue (4581060) is valid, not the other
one (4518052).
I like new shapes too, with one exception: the very smallest brace has
it's center too far to the left i think.

http://codereview.appspot.com/4581060/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: separating flags from noteheads in font (issue4273119)

2011-06-26 Thread lemniskata . bernoullego


This is now abandoned; a new (working) version was created by Carl here:
http://codereview.appspot.com/4662055/
(google code issue 1709)

cheers,
Janek

http://codereview.appspot.com/4273119/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Small pitch bends correct and tested. (issue4654063)

2011-06-25 Thread lemniskata . bernoullego


Reviewers: gbreed,

Message:
Graham Breed wrote:

I've found and patched two problems with the pitch bend
tuning code:

1) The pitch isn't always rounded to the nearest equally
tempered value, so the result looks strange in a sequencer,
and artifacts caused by the pitch bends are more severe.

2) The tuning is rounded to cents before the pitch bends
are calculated.  It may not be a big deal, but there's no
need for it, and the code's simpler calculating the bends
directly.

I don't think either of these are registered issues.  As
I'm new with Git, the two issues are mixed in the two
patches.  Problem (1) is fixed in get_semitone_pitch().
It's just a question of rounding off the result.
Everything else is for problem (2).


Description:
Small pitch bends correct and tested.

Pitch bends are not rounded to cents.

Pitch bends of full precision centered on zero.

Please review this at http://codereview.appspot.com/4654063/

Affected files:
  M lily/midi-item.cc


Index: lily/midi-item.cc
diff --git a/lily/midi-item.cc b/lily/midi-item.cc
index  
1fcb259ae13c2c0b6b0ee94967476cd8099f3928..02bdd7ac84b1e09cd44afb71873da4984d494a03  
100644

--- a/lily/midi-item.cc
+++ b/lily/midi-item.cc
@@ -28,10 +28,8 @@
 #include "string-convert.hh"
 #include "warn.hh"

-#define PITCH_WHEEL_TOP 0x3FFF
 #define PITCH_WHEEL_CENTER 0x2000
-#define PITCH_WHEEL_BOTTOM 0x
-#define PITCH_WHEEL_RANGE (PITCH_WHEEL_TOP - PITCH_WHEEL_BOTTOM)
+#define PITCH_WHEEL_SEMITONE 0X1000

 Midi_item *
 Midi_item::get_midi (Audio_item *a)
@@ -193,15 +191,16 @@ Midi_note::get_fine_tuning () const
   + audio_->transposing_.tone_pitch ()) * Rational (2);
   tune -= Rational (get_semitone_pitch ());

-  tune *= 100;
+  tune *= PITCH_WHEEL_SEMITONE;
   return (int) double (tune);
 }

 int
 Midi_note::get_semitone_pitch () const
 {
-  return int (double ((audio_->pitch_.tone_pitch ()
-  + audio_->transposing_.tone_pitch ()) * Rational (2)));
+  double tune = double ((audio_->pitch_.tone_pitch ()
+  + audio_->transposing_.tone_pitch ()) * Rational (2));
+  return (tune > 0)? int (tune + 0.5): int(tune - 0.5);
 }

 string
@@ -214,10 +213,7 @@ Midi_note::to_string () const
   // print warning if fine tuning was needed, HJJ
   if (get_fine_tuning () != 0)
 {
-  finetune = PITCH_WHEEL_CENTER;
-  // Move pitch wheel to a shifted position.
-  // The pitch wheel range (of 4 semitones) is multiplied by the cents.
-  finetune += (PITCH_WHEEL_RANGE *get_fine_tuning ()) / (4 * 100);
+  finetune = PITCH_WHEEL_CENTER + get_fine_tuning();

   str += ::to_string ((char) (0xE0 + channel_));
   str += ::to_string ((char) (finetune & 0x7F));



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Flag functions instead of defining glyphs directly (issue4625067)

2011-06-25 Thread lemniskata . bernoullego


Reviewers: carl.d.sorensen_gmail.com, MikeSol,

Message:
This is an intermediate step that will be needed for shortened flags.

Description:
Flag functions instead of defining glyphs directly

We will need many length variants of every flag.
Therefore instead of writing flag code directly
in glyph definition, it should be written as
a function and called back later as appropriate.
The argument shortening is the amount the flag
should be shorter than default.
As for now it is used in a very primitive way,
only to demonstrate the shortening effect
and to test c++ code on something.

Please review this at http://codereview.appspot.com/4625067/

Affected files:
  M mf/feta-flags.mf



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add feta-flags to build system (issue4662055)

2011-06-25 Thread lemniskata . bernoullego


Carl!

Woot! It works! I compiled it twice, and everything looks fine!!
I told you you are a genious, didn't i? :D
Do i understand correctly that a variable is available to all fonts
(fet_beginfont ... fet_endfont) which are in the same mf file - it's so
simple?
So you solved the problem by calling noteheads and flags together, but
there had to be two separate mf files so that there will be two separate
"fonts", and that's why this stuff is doubled?


http://codereview.appspot.com/4662055/diff/1/mf/GNUmakefile
File mf/GNUmakefile (right):

http://codereview.appspot.com/4662055/diff/1/mf/GNUmakefile#newcode20
mf/GNUmakefile:20: $(call src-wildcard,feta-flags*[0-9].mf) \
What does this exactly mean? Is it simply "feta-flags11.mf,
feta-flags13.mf (and so on) should be processed when make is called"?

http://codereview.appspot.com/4662055/diff/1/mf/bigcheese.pe.in
File mf/bigcheese.pe.in (right):

http://codereview.appspot.com/4662055/diff/1/mf/bigcheese.pe.in#newcode14
mf/bigcheese.pe.in:14: MergeFonts("feta-flags20.pfa");
This glues the fonts together,, but only after everything else was
calculated?
Why only design size 20 appears here?

http://codereview.appspot.com/4662055/diff/1/mf/feta-flags-generic.mf
File mf/feta-flags-generic.mf (right):

http://codereview.appspot.com/4662055/diff/1/mf/feta-flags-generic.mf#newcode36
mf/feta-flags-generic.mf:36: %%including feta-noteheads.
I suggest adding a warning "Be aware! The value 1.0 staff space is a
dummy value, not connected to the actual width of the notehead" to this
comment. It's easy to be fooled at the beginning.

http://codereview.appspot.com/4662055/diff/1/mf/feta-noteheads-generic.mf
File mf/feta-noteheads-generic.mf (right):

http://codereview.appspot.com/4662055/diff/1/mf/feta-noteheads-generic.mf#newcode36
mf/feta-noteheads-generic.mf:36: %%including feta-noteheads.
I suggest adding a warning "Be aware! The value 1.0 staff space is a
dummy value, not connected to the actual width of the notehead" to this
comment. It's easy to be fooled at the beginning.

http://codereview.appspot.com/4662055/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ambitus: special handling of small ambits' lines (issue4609041)

2011-06-21 Thread lemniskata . bernoullego



http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/4609041/diff/12001/scm/define-grobs.scm#newcode141
scm/define-grobs.scm:141: (woot . 1)
On 2011/06/17 07:18:49, MikeSol wrote:

This seems like 1337 $p34k -
I have never heard woot in any other context.
Perhaps change to something more descriptive?


Of course!
I had no idea for the name and decided to use a placeholder and ask you
instead of wasting 15 minutes on something so simple (i was quite tired
when i wrote this code).

http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm
File scm/output-lib.scm (right):

http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode944
scm/output-lib.scm:944: (linear-gap (+ (max gap-property 0.3) -0.45
On 2011/06/17 07:18:49, MikeSol wrote:

Indentation: the -0.45 should be on the next line & lined up with the
left-parenthesis of (max.


Done.

http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode950
scm/output-lib.scm:950: (unwooted (max (min calculated-gap gap-property)
(/ gap-property 4.5)))
On 2011/06/17 07:18:49, MikeSol wrote:

80 column max


Done.

http://codereview.appspot.com/4609041/diff/12001/scm/output-lib.scm#newcode951
scm/output-lib.scm:951: (gap (+ (* unwooted woot) (* gap-property (- 1
woot
On 2011/06/17 07:18:49, MikeSol wrote:

This codes a lot of properties.  I'm fine with the code (though I'd

need to see

a regtest).  Can you try using a "details" property (like for the Beam

grob)

that stores all of these values?


Umm, I don't want to define properties like linear-gap, calculated-gap
etc. They are just temporary variables so that the code calculating
final gap is easier to read. Had i not used them, i would have to write
everything explicitely like this (with better indentation perhaps):

(gap
  (+
(*
  (max
(min
  (if
(<
  (+
(max (ly:grob-property grob 'gap 0.35) 0.3)
-0.45
(*
  0.2
  (-
(interval-start (ly:grob-extent head-up common Y))
(interval-end (ly:grob-extent head-down common
Y)
  0.2)
(+
  (max (ly:grob-property grob 'gap 0.35) 0.3)
  -0.45
  (*
0.2
(-
  (interval-start (ly:grob-extent head-up common Y))
  (interval-end (ly:grob-extent head-down common Y)
(+
  (*
(floor
  (/
(-
  (+
(max (ly:grob-property grob 'gap 0.35) 0.3)
-0.45
(*
  0.2
  (-
(interval-start (ly:grob-extent head-up
common Y))
(interval-end (ly:grob-extent head-down
common Y)
  0.2)
0.25))
0.25)
  0.2))
  (ly:grob-property grob 'gap 0.35))
(/ (ly:grob-property grob 'gap 0.35) 4.5))
  (ly:grob-property grob 'woot 1))
(* (ly:grob-property grob 'gap 0.35)
   (- 1 (ly:grob-property grob 'woot 1)

looks suicidal...
When i noticed that point-max and point-min don't seem to be any
properties but only a sort of temporary variables, i used this idea for
my piece of code. Maybe i didn't understand how this works...

http://codereview.appspot.com/4609041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: doc: fixing snippet fretted-string-harmonics (issue4624041)


On 2011/06/15 10:27:09, graham_percival-music.ca wrote:

thanks, pushed.


thanks, issue closed.

cheers,
Janek

http://codereview.appspot.com/4624041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

doc: fixing snippet fretted-string-harmonics (issue4624041)


Reviewers: Graham Percival, fedelogy_gmail.com,

Message:
A fix of fretted-string-harmonics-in-tablature.ly snippet by Federico
Bruni.
This fixes erroneus notation, for example harmonics at the beginning
should be an octave higher than base note, not two octaves higher.

Description:
doc: fixing snippet fretted-string-harmonics

fretted-string-harmonics-in-tablature.ly
contained some mistakes (erroneus notation)

Please review this at http://codereview.appspot.com/4624041/

Affected files:
  M Documentation/snippets/fretted-string-harmonics-in-tablature.ly
  M Documentation/snippets/new/fretted-string-harmonics-in-tablature.ly


Index: Documentation/snippets/fretted-string-harmonics-in-tablature.ly
diff --git  
a/Documentation/snippets/fretted-string-harmonics-in-tablature.ly  
b/Documentation/snippets/fretted-string-harmonics-in-tablature.ly
index  
d91c0042cb86307ca8e10a978487552f386aba93..00c9577d5a1273787e471b3fa6abda61abb2f11d  
100644

--- a/Documentation/snippets/fretted-string-harmonics-in-tablature.ly
+++ b/Documentation/snippets/fretted-string-harmonics-in-tablature.ly
@@ -46,13 +46,13 @@ pinchedHarmonics = {
 harmonics = {
   %artificial harmonics (AH)
   \textLengthOn
-  <\parenthesize b b''\harmonic>4_\markup{ \teeny "AH 16" }
-  <\parenthesize g g''\harmonic>4_\markup{ \teeny "AH 17" }
-  <\parenthesize d' d'''\harmonic>2_\markup{ \teeny "AH 19" }
+  <\parenthesize b b'\harmonic>4_\markup{ \teeny "AH 16" }
+  <\parenthesize g g'\harmonic>4_\markup{ \teeny "AH 17" }
+  <\parenthesize d' d''\harmonic>2_\markup{ \teeny "AH 19" }
   %pinched harmonics (PH)
   \pinchedHarmonics
   2\startTextSpan
-  4
+  4
   4\stopTextSpan
   %tapped harmonics (TH)
   <\parenthesize g\4 g'\harmonic>4_\markup{ \teeny "TH 17" }
@@ -73,8 +73,8 @@ frettedStrings = {
   \harmonicByFret #7 a4\5
   %tapped harmonics (TH)
   \harmonicByFret #5 d4\4
-  \harmonicByFret #5 d4\4
-  \harmonicByFret #4 g2\3
+  \harmonicByFret #7 d4\4
+  \harmonicByFret #5 g2\3
   %touch harmonics (TCH)
   a4 \harmonicByFret #9 g2.\3
 }
Index: Documentation/snippets/new/fretted-string-harmonics-in-tablature.ly
diff --git  
a/Documentation/snippets/new/fretted-string-harmonics-in-tablature.ly  
b/Documentation/snippets/new/fretted-string-harmonics-in-tablature.ly
index  
4c42958a7b356583eaa6186e587b5caa25068cb3..ed942c9b31cf59147fc6b904205221db24c75ed3  
100644

--- a/Documentation/snippets/new/fretted-string-harmonics-in-tablature.ly
+++ b/Documentation/snippets/new/fretted-string-harmonics-in-tablature.ly
@@ -24,13 +24,13 @@ pinchedHarmonics = {
 harmonics = {
   %artificial harmonics (AH)
   \textLengthOn
-  <\parenthesize b b''\harmonic>4_\markup{ \teeny "AH 16" }
-  <\parenthesize g g''\harmonic>4_\markup{ \teeny "AH 17" }
-  <\parenthesize d' d'''\harmonic>2_\markup{ \teeny "AH 19" }
+  <\parenthesize b b'\harmonic>4_\markup{ \teeny "AH 16" }
+  <\parenthesize g g'\harmonic>4_\markup{ \teeny "AH 17" }
+  <\parenthesize d' d''\harmonic>2_\markup{ \teeny "AH 19" }
   %pinched harmonics (PH)
   \pinchedHarmonics
   2\startTextSpan
-  4
+  4
   4\stopTextSpan
   %tapped harmonics (TH)
   <\parenthesize g\4 g'\harmonic>4_\markup{ \teeny "TH 17" }
@@ -51,8 +51,8 @@ frettedStrings = {
   \harmonicByFret #7 a4\5
   %tapped harmonics (TH)
   \harmonicByFret #5 d4\4
-  \harmonicByFret #5 d4\4
-  \harmonicByFret #4 g2\3
+  \harmonicByFret #7 d4\4
+  \harmonicByFret #5 g2\3
   %touch harmonics (TCH)
   a4 \harmonicByFret #9 g2.\3
 }



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bugfix for issue 1630 (issue4490045)


indent indent indent


http://codereview.appspot.com/4490045/diff/25003/lily/tie-engraver.cc
File lily/tie-engraver.cc (right):

http://codereview.appspot.com/4490045/diff/25003/lily/tie-engraver.cc#newcode189
lily/tie-engraver.cc:189: /*
On 2011/06/14 23:07:54, Graham Percival wrote:

these should be tabs


aaa!!!
Done!
But the indentation in this place is generally screwed, even besides
tabs/spaces!
!!

http://codereview.appspot.com/4490045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: describing regression checking more explicitely (issue4621041)


As you wish :)


http://codereview.appspot.com/4621041/diff/5001/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/4621041/diff/5001/Documentation/contributor/regressions.itexi#newcode201
Documentation/contributor/regressions.itexi:201: @warning{
On 2011/06/15 08:21:32, Graham Percival wrote:

On 2011/06/15 08:14:54, Janek Warchol wrote:
> Maybe it would be better placed at the bottom or over point 5?
> Should this be an Advanced note?



move it to an advanced note at the bottom of the page.  It's certainly

not

important enough to be a warning; we want to "save" those for truly

important

stuff.


Done.

http://codereview.appspot.com/4621041/diff/5001/Documentation/contributor/regressions.itexi#newcode207
Documentation/contributor/regressions.itexi:207: @code{make} and
@code{make check} it (without doing @code{make test-baseline}
On 2011/06/15 08:21:32, Graham Percival wrote:

remove the parenthesis, just end with:
@code{make} and @code{make check} it without doing @code{make

test-baseline}

again.


Done.

http://codereview.appspot.com/4621041/diff/5001/Documentation/contributor/regressions.itexi#newcode224
Documentation/contributor/regressions.itexi:224: available at:
On 2011/06/15 08:21:32, Graham Percival wrote:

available (relative to the current build/ directory) at:


Done.

http://codereview.appspot.com/4621041/diff/5001/Documentation/contributor/regressions.itexi#newcode227
Documentation/contributor/regressions.itexi:227:
lilypond-git/build/out/test-results/index.html
On 2011/06/15 08:21:32, Graham Percival wrote:

second thought: I think I prefer:
out/test-results/index.html



in order to not confuse people, see above comment.


Done.

http://codereview.appspot.com/4621041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

doc: fixing snippet fretted-string-harmonics (issue4576062)


Reviewers: Graham Percival, fedelogy_gmail.com,

Message:
I shouldn't have called scripts/auxiliar/makelsr.py?

Description:
doc: fixing snippet fretted-string-harmonics

I probably made it the wrong way - i changed
Documentation/snippets/new/
fretted-string-harmonics-in-tablature.ly
and called scripts/auxiliar/makelsr.py from
lilypond-git.
This resulted in loads of changes...

Please review this at http://codereview.appspot.com/4576062/

Affected files:
  M Documentation/snippets/accordion-discant-symbols.ly
  M Documentation/snippets/adding-a-figured-bass-above-or-below-the-notes.ly
  M Documentation/snippets/adding-ambitus-per-voice.ly
  M Documentation/snippets/adding-an-extra-staff-at-a-line-break.ly
  M Documentation/snippets/adding-an-extra-staff.ly
  M Documentation/snippets/adding-bar-lines-to-chordnames-context.ly
  M  
Documentation/snippets/adding-beams,-slurs,-ties-etc.-when-using-tuplet-and-non-tuplet-rhythms.ly

  M Documentation/snippets/adding-drum-parts.ly
  M Documentation/snippets/adding-fingerings-to-tablatures.ly
  M Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly
  M  
Documentation/snippets/adding-parentheses-around-an-expressive-mark-or-chordal-note.ly

  M Documentation/snippets/adding-the-current-date-to-a-score.ly
  M Documentation/snippets/adding-volta-brackets-to-additional-staves.ly
  M Documentation/snippets/additional-voices-to-avoid-collisions.ly
  M Documentation/snippets/adjusting-grace-note-spacing.ly
  M Documentation/snippets/adjusting-lyrics-vertical-spacing.ly
  M Documentation/snippets/adjusting-the-shape-of-falls-and-doits.ly
  M Documentation/snippets/aligning-and-centering-instrument-names.ly
  M Documentation/snippets/aligning-bar-numbers.ly
  M Documentation/snippets/aligning-marks-with-various-notation-objects.ly
  M  
Documentation/snippets/allowing-fingerings-to-be-printed-inside-the-staff.ly

  M Documentation/snippets/altering-the-length-of-beamed-stems.ly
  M Documentation/snippets/alternative-breve-note.ly
  M Documentation/snippets/ambitus-with-multiple-voices.ly
  M Documentation/snippets/analysis-brackets-above-the-staff.ly
  M Documentation/snippets/ancient-fonts.ly
  M Documentation/snippets/ancient-headword.ly
  M  
Documentation/snippets/ancient-notation-templatemodern-transcription-of-gregorian-music.ly
  M  
Documentation/snippets/ancient-notation-templatemodern-transcription-of-mensural-music.ly

  M Documentation/snippets/ancient-time-signatures.ly
  M  
Documentation/snippets/applying-note-head-styles-depending-on-the-step-of-the-scale.ly

  M Documentation/snippets/arabic-improvisation.ly
  M Documentation/snippets/asymmetric-slurs.ly
  M Documentation/snippets/automatic-beam-subdivisions.ly
  M Documentation/snippets/avoiding-collisions-with-chord-fingerings.ly
  M Documentation/snippets/beam-endings-in-score-context.ly
  M Documentation/snippets/beam-grouping-in-7-8-time.ly
  M Documentation/snippets/beams-across-line-breaks.ly
  M  
Documentation/snippets/blanking-staff-lines-using-the--whiteout-command.ly

  M Documentation/snippets/broken-crescendo-hairpin.ly
  M Documentation/snippets/caesura-railtracks-with-fermata.ly
  M Documentation/snippets/center-text-below-hairpin-dynamics.ly
  M Documentation/snippets/centering-markup-on-note-heads-automatically.ly
  M Documentation/snippets/changing--flageolet-mark-size.ly
  M Documentation/snippets/changing-a-single-notes-size-in-a-chord.ly
  M Documentation/snippets/changing-beam-knee-gap.ly
  M Documentation/snippets/changing-chord-separator.ly
  M Documentation/snippets/changing-form-of-multi-measure-rests.ly
  M Documentation/snippets/changing-fret-orientations.ly
  M Documentation/snippets/changing-midi-output-to-one-channel-per-voice.ly
  M Documentation/snippets/changing-partcombine-texts.ly
  M  
Documentation/snippets/changing-text-and-spanner-styles-for-text-dynamics.ly

  M Documentation/snippets/changing-the-ambitus-gap.ly
  M  
Documentation/snippets/changing-the-appearance-of-a-slur-from-solid-to-dotted-or-dashed.ly

  M Documentation/snippets/changing-the-breath-mark-symbol.ly
  M  
Documentation/snippets/changing-the-chord-names-to-german-or-semi-german-notation.ly
  M  
Documentation/snippets/changing-the-number-of-augmentation-dots-per-note.ly
  M  
Documentation/snippets/changing-the-positions-of-figured-bass-alterations.ly

  M Documentation/snippets/changing-the-size-of-woodwind-diagrams.ly
  M Documentation/snippets/changing-the-tempo-without-a-metronome-mark.ly
  M Documentation/snippets/changing-the-text-for-sustain-markings.ly
  M  
Documentation/snippets/changing-the-time-signature-without-affecting-the-beaming.ly

  M Documentation/snippets/changing-the-tuplet-number.ly
  M  
Documentation/snippets/changing-time-signatures-inside-a-polymetric-section-using--scaledurations.ly

  M Documentation/snippets/chant-or-psalms-notation.ly
  M Documentation/snippets/chord-glissando-in-tablature.ly
  M Documentation/snippets/chord-name-exceptions.ly

Re: describing regression checking more explicitely (issue4621041)

@Graham:
perfect! you caught exactly the subtleties which i was worrying that
might be there!

http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi#newcode191
Documentation/contributor/regressions.itexi:191: Ensure that currently
built binary is the one without your changes.
On 2011/06/14 22:01:49, Graham Percival wrote:

On 2011/06/14 21:40:37, Janek Warchol wrote:
> I think a beginner can overlook this step.

Let's change that to:
Run @code{make} with current git master without any of your changes.

Done.

http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi#newcode201
Documentation/contributor/regressions.itexi:201: in
@file{lilypond-git/build/} directory.
On 2011/06/14 22:01:49, Graham Percival wrote:

On 2011/06/14 21:40:37, Janek Warchol wrote:
> i remember that it wasn't obvious for me whether to run
> make test-baseline
> in lilypond-git/ or in lilypond-git/build/.

ok.  Could we make this:

Before making changes to the code, establish a baseline for the

comparison by

going to the @file{lilypond-git/build/} directory and running:

?  I prefer not to have text underneath an example.

Done.

http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi#newcode220
Documentation/contributor/regressions.itexi:220:
build/out/test-results/index.html
On 2011/06/14 22:01:49, Graham Percival wrote:

hmm.  Relative to the current directory, it's only
   out/test-results/index.html

since the build directory itself has a build/ subdir (Colin calls this
"elephants all the way down"), I think this could be confusing.

What about specifying
   lilypond-git/build/...

?

Done.

http://codereview.appspot.com/4621041/diff/5001/Documentation/contributor/regressions.itexi#newcode201
Documentation/contributor/regressions.itexi:201: in
@file{lilypond-git/build/} directory.
Maybe it would be better placed at the bottom or over point 5?
Should this be an Advanced note?

http://codereview.appspot.com/4621041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ambitus: special handling of small ambits' lines (issue4609041)


2011/6/13 Trevor Daniels :


Janek Warchoł wrote Monday, June 13, 2011 2:51 PM



2011/6/13  :



a) It would be better to honour the value of 'gap if this
is set by the user, rather than change a specifically
requested gap value.



My rationale is that it wouldn't make sense to set a big gap and
really want to have it applied to all ambituses.



Your algorithm is fine as the default behaviour, but it does remove

the

ability for a user to precisely set the gap he wants by setting 'gap,
for whatever reason.  This seems counter to Lily's flexible user

control,

but I don't feel too strongly about it.


Ok, let's give the user precise control.
I added a parameter which controlls this, but no reasonable name for it
(and for some intermediate stages in the code) comes to my mind.
Any suggestions to what should i change "woot" and "unwooted"?

Also, adding a new property means it has to be written somewhere -
i only found define-grobs.scm, but this is not enough: i get the
following
warning when i compile

warning: cannot find property type-check for `woot' (backend-type?).
 perhaps a typing error?
warning: doing assignment anyway

Where else should i include it? I tried searching for "AmbitusLine",
but the only files i got (besides docs) were the two that i have.



Ofc i'm aware that this [quanting] is perhaps as nitpicky as it can

go :D


OK.  It is! :)   Does it scale correctly with large and small values

of

global staff-size?


Yes, the quanting stays the same.

cheers,
Janek

http://codereview.appspot.com/4609041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bugfix for issue 1630 (issue4490045)

2011-06-14 Thread lemniskata . bernoullego


Thanks to Neil's help, it's done.


http://codereview.appspot.com/4490045/diff/30001/lily/tie-engraver.cc
File lily/tie-engraver.cc (right):

http://codereview.appspot.com/4490045/diff/30001/lily/tie-engraver.cc#newcode157
lily/tie-engraver.cc:157: maybe should check positions too.
On 2011/06/14 21:36:59, Neil Puttock wrote:

looks like tab -> space conversion going on here (and below); please

restore and

only fix bad indents


Done.

http://codereview.appspot.com/4490045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

describing regression checking more explicitely (issue4621041)

2011-06-14 Thread lemniskata . bernoullego


Reviewers: Graham Percival, james.lowe_datacore.com,

Message:
A small change to the CG to make things more obvious for the beginners.
I hope that what i wrote is true ;)

Rewording suggestions are most welcome.


http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi
File Documentation/contributor/regressions.itexi (right):

http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi#newcode191
Documentation/contributor/regressions.itexi:191: Ensure that currently
built binary is the one without your changes.
I think a beginner can overlook this step.

http://codereview.appspot.com/4621041/diff/1/Documentation/contributor/regressions.itexi#newcode201
Documentation/contributor/regressions.itexi:201: in
@file{lilypond-git/build/} directory.
i remember that it wasn't obvious for me whether to run
make test-baseline
in lilypond-git/ or in lilypond-git/build/.

Description:
describing regression checking more explicitely

Please review this at http://codereview.appspot.com/4621041/

Affected files:
  M Documentation/contributor/regressions.itexi


Index: Documentation/contributor/regressions.itexi
diff --git a/Documentation/contributor/regressions.itexi  
b/Documentation/contributor/regressions.itexi
index  
3ec39d49cf201b83e7beaaa516a7e4bff66bf28d..50b038b71876356c4250987c817469e896cc1811  
100644

--- a/Documentation/contributor/regressions.itexi
+++ b/Documentation/contributor/regressions.itexi
@@ -188,13 +188,18 @@ twice.
 @enumerate

 @item
-Before making changes, a baseline should be established by
-running:
+Ensure that currently built binary is the one without your changes.
+
+@item
+Before making changes to the code, establish a baseline for the
+comparison by running:

 @example
 make test-baseline
 @end example

+in @file{lilypond-git/build/} directory.
+
 @item
 Make your changes, or apply the patch(es) to consider.

@@ -212,7 +217,7 @@ After this has finished, a regression test comparison  
will be

 available at:

 @example
-out/test-results/index.html
+build/out/test-results/index.html
 @end example

 For each regression test that differs between the baseline and the



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bugfix for issue 1630 (issue4490045)

2011-06-14 Thread lemniskata . bernoullego


New patch set uploaded, i think all formatting issues are resolved.
Should i run the regtests again?


http://codereview.appspot.com/4490045/diff/20001/lily/completion-note-heads-engraver.cc
File lily/completion-note-heads-engraver.cc (right):

http://codereview.appspot.com/4490045/diff/20001/lily/completion-note-heads-engraver.cc#newcode204
lily/completion-note-heads-engraver.cc:204:
event->set_property("autosplit-end",
On 2011/06/01 21:21:25, Neil Puttock wrote:

set_property (


Done.

http://codereview.appspot.com/4490045/diff/20001/lily/completion-note-heads-engraver.cc#newcode205
lily/completion-note-heads-engraver.cc:205: ly_bool2scm (left_to_do_ -
note_dur.get_length () > Rational (0)));
On 2011/06/01 21:21:25, Neil Puttock wrote:

indent:



event->set_property ("autosplit-end",
  ly_bool2scm (


Done.

http://codereview.appspot.com/4490045/diff/20001/lily/tie-engraver.cc
File lily/tie-engraver.cc (right):

http://codereview.appspot.com/4490045/diff/20001/lily/tie-engraver.cc#newcode85
lily/tie-engraver.cc:85: bool has_autosplit_end (Stream_event* event);
On 2011/06/01 21:21:25, Neil Puttock wrote:

Stream_event *event


Done.

http://codereview.appspot.com/4490045/diff/20001/lily/tie-engraver.cc#newcode125
lily/tie-engraver.cc:125: Tie_engraver::has_autosplit_end (Stream_event*
event)
On 2011/06/01 21:21:25, Neil Puttock wrote:

Stream_event *event


Done.

http://codereview.appspot.com/4490045/diff/20001/lily/tie-engraver.cc#newcode163
lily/tie-engraver.cc:163: /*
On 2011/06/13 22:51:39, Graham Percival wrote:

On 2011/06/13 22:44:37, karin.hoethker wrote:
> On 2011/06/01 21:21:25, Neil Puttock wrote:
> > indent
>
> I don't see a problem here.



The /* should line up with the "if" on line 159.  Line 167 should also

line up

with line 159.


Done.

http://codereview.appspot.com/4490045/diff/20001/lily/tie-engraver.cc#newcode163
lily/tie-engraver.cc:163: /*
On 2011/06/01 21:21:25, Neil Puttock wrote:

indent


Done.

http://codereview.appspot.com/4490045/diff/20001/lily/tie-engraver.cc#newcode289
lily/tie-engraver.cc:289: if (left_ev && (tie_event || tie_stream_event)
On 2011/06/01 21:21:25, Neil Puttock wrote:

indent


Done.

http://codereview.appspot.com/4490045/diff/20001/scm/define-music-properties.scm
File scm/define-music-properties.scm (right):

http://codereview.appspot.com/4490045/diff/20001/scm/define-music-properties.scm#newcode44
scm/define-music-properties.scm:44: (autosplit-end ,boolean? "Duration
of event was truncated by automatic splitting in
Completion_heads_engraver.")
On 2011/06/01 21:21:25, Neil Puttock wrote:

the @code{Completion_heads_engraver}.


Done.

http://codereview.appspot.com/4490045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: doc: changing example for overriding positions (issue4607043)

2011-06-13 Thread lemniskata . bernoullego


Style problems corrected.
Thanks for review, Neil!


http://codereview.appspot.com/4607043/diff/1/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):

http://codereview.appspot.com/4607043/diff/1/Documentation/learning/tweaks.itely#newcode2801
Documentation/learning/tweaks.itely:2801: \time 4/2
On 2011/06/12 14:09:09, Neil Puttock wrote:

judging by the bar checks, I think you mean 4/4


Sorry, barchecks were wrong. It was 4/4 at first, but should be 4/2.

http://codereview.appspot.com/4607043/diff/1/Documentation/learning/tweaks.itely#newcode2803
Documentation/learning/tweaks.itely:2803: { c'1 ~ c'2. e'8 f'}
On 2011/06/12 14:09:09, Neil Puttock wrote:

space before }


Done.

http://codereview.appspot.com/4607043/diff/1/Documentation/learning/tweaks.itely#newcode2829
Documentation/learning/tweaks.itely:2829: \override Beam #'positions =
#'(-1 . -1)
On 2011/06/12 14:09:09, Neil Puttock wrote:

please put this inside the sequential block:



{
   \override Beam #'positions = #'(-1 . -1)
   e''8 ...
}


Done.

http://codereview.appspot.com/4607043/diff/1/Documentation/learning/tweaks.itely#newcode2842
Documentation/learning/tweaks.itely:2842: the second measure of quavers,
but not to any of the beams in the
On 2011/06/12 14:09:09, Neil Puttock wrote:

of eighth notes,


Done.

http://codereview.appspot.com/4607043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: ambitus: special handling of small ambits' lines (issue4609041)

2011-06-13 Thread lemniskata . bernoullego


On 2011/06/13 08:01:22, Trevor Daniels wrote:

The interpersed comments make it very difficult to read
the code.  Could you place an abridged summary at the top
instead?


Done.
I write a lot of comments so that rookies like me would be able to
understand the code in finite time, if they happen to work on this in
the future ;)

http://codereview.appspot.com/4609041/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

ambitus: special handling of small ambits' lines (issue4609041)

2011-06-12 Thread lemniskata . bernoullego


Reviewers: Mike,

Description:
ambitus: special handling of small ambits' lines

Until now, it was not possible to have all ambits
look good: either the gaps between ambit line
and heads were too big for ambits of 4th and 5th,
or they were too small for other ambits.
This patch introduces automatic scaling
of the gap between heads and line: bigger ambits
are left unchanged, but smaller have their gap
diminished so that the line is long enough.

Please review this at http://codereview.appspot.com/4609041/

Affected files:
  M scm/output-lib.scm


Index: scm/output-lib.scm
diff --git a/scm/output-lib.scm b/scm/output-lib.scm
index  
c25edf31f68a93de749a87e69e26cd4dde6dfc3d..dc2ff7a159313545f08fbfcb135a4a11b9f323fa  
100644

--- a/scm/output-lib.scm
+++ b/scm/output-lib.scm
@@ -915,13 +915,44 @@ between the two text elements."
(let* ((common (ly:grob-common-refpoint-of-array grob heads Y))
   (head-down (ly:grob-array-ref heads 0))
   (head-up (ly:grob-array-ref heads 1))
-  (gap (ly:grob-property grob 'gap 0.35))
+  ;; top of lower ambitus head:
+  (ground (interval-end (ly:grob-extent head-down common Y)))
+  ;; bottom of upper ambitus head:
+  (roof (interval-start (ly:grob-extent head-up common Y)))
+  ;; total amount of space between ambitus heads -
+  ;; our task is to decide how much of this space will be occupied
+  ;; by the ambitus line. We do this by calculating how big the 
gaps
+  ;; between ambitus line and ambitus heads will be.
+  (space-between-heads (- roof ground))
+  ;; read the property - this is our starting point;
+  ;; we are going to adjust it to fit small ambituses better:
+  (gap-property (ly:grob-property grob 'gap 0.35))
+  ;; We calculate a theoretical gap size using a linear function.
+  ;; the function was determined by trial-and-error; it's main
+  ;; premises are: gap is proportional to space between heads,
+  ;; big value in gap property means that small ambituses won't
+  ;; have any line at all, for values around 0.45 (default)
+  ;; gap approaches 0 when distance betweeen heads approaches 0,
+  ;; and it shouldn't reach 0 too soon with very small values.
+  (proportional (+ (max gap-property 0.3) -0.45
+ (* 0.2 space-between-heads)))
+  ;; ambitus line looks best if the gap value is quanted.
+  ;; optimal quants are: 0.2 0.45 0.7 0.95 1.2 etc.
+	   (quanted-gap (+ (* (floor (/ (- proportional 0.2) 0.25)) 0.25)  
0.2))

+  ;; we don't want to quant gap values smaller than 0.2
+  ;; (because quanting them would mean making them 0).
+  (theoretical (if (< proportional 0.2) proportional quanted-gap))
+  ;; The above calculations are mainly for small ambituses;
+  ;; in case of bigger ones they would lead to very big gaps
+  ;; so we restrict them by the value written in the gap property.
+  ;; we also don't want gap values too close to 0, hence the max.
+  (gap (max (min theoretical gap-property) (/ gap-property 4.5)))
   (point-min (+ (interval-end (ly:grob-extent head-down common Y))
 gap))
   (point-max (- (interval-start (ly:grob-extent head-up common Y))
 gap)))

- (if (< point-min point-max)
+	  (if (< (+ point-min 0.1) point-max) ;; don't print lines shorter than  
0.1

  (let* ((layout (ly:grob-layout grob))
 (line-thick (ly:output-def-lookup layout 'line-thickness))
 (blot (ly:output-def-lookup layout 'blot-diameter))



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

doc: changing example for overriding positions (issue4607043)

2011-06-12 Thread lemniskata . bernoullego


Reviewers: Graham Percival,

Description:
doc: changing example for overriding positions

example in LM 4.5.2 (fixing beam collision)
is outdated because beam collision has been
implemented, so there is nothing to fix.
Therefore I change the type of collision
to beam-tie collision.

Please review this at http://codereview.appspot.com/4607043/

Affected files:
  M Documentation/learning/tweaks.itely


Index: Documentation/learning/tweaks.itely
diff --git a/Documentation/learning/tweaks.itely  
b/Documentation/learning/tweaks.itely
index  
97b2cadfd9744d9f432379e93338f9303349185e..d3c2ab156eb0d6baa5a0eaea39d43ef64f30fdfe  
100644

--- a/Documentation/learning/tweaks.itely
+++ b/Documentation/learning/tweaks.itely
@@ -2793,42 +2793,53 @@ r4
 \acciaccatura e8\( d8 c~ c d c d\)
 @end lilypond

-Here's a further example taken from the opening of the left-hand
-staff of Chopin's Prelude Op 28 No. 2.  We see that the beam
-collides with the upper notes:
+Here's a further example.  We see that the beams
+collide with the ties:

 @lilypond[quote,verbatim,fragment,ragged-right]
 {
-  \clef "bass"
-  << { b,8 ais, b, g, } \\ { e,8 g e, g } >>
-  << { b,8 ais, b, g, } \\ { e,8 g e, g } >>
+  \time 4/2
+  <<
+{ c'1 ~ c'2. e'8 f'}
+\\
+{ e''8 e'' e'' e''  e'' e'' e'' e'' | f''2 g''}
+  >>
+  <<
+{ c'1 ~ c'2. e'8 f'}
+\\
+{ e''8 e'' e'' e''  e'' e'' e'' e'' | f''2 g''}
+  >>
 }
 @end lilypond

 @noindent
 This can be resolved by manually moving both ends of the beam
-up from their position at 2 staff-spaces above the center line to,
-say, 3:
+up from their position at 1.81 staff-spaces below the center line to,
+say, 1:

 @cindex Beam, example of overriding
 @cindex positions property, example

 @lilypond[quote,verbatim,fragment,ragged-right]
 {
-  \clef "bass"
+  \time 4/2
   <<
-\override Beam #'positions = #'(3 . 3)
-{ b,8 ais, b, g, }
-  \\
-{ e,8 g e, g }
+{ c'1 ~ c'2. e'8 f'}
+\\
+\override Beam #'positions = #'(-1 . -1)
+{ e''8 e'' e'' e''  e'' e'' e'' e'' | f''2 g''}
+  >>
+  <<
+{ c'1 ~ c'2. e'8 f'}
+\\
+{ e''8 e'' e'' e''  e'' e'' e'' e'' | f''2 g''}
   >>
-  << { b,8 ais, b, g, } \\ { e,8 g e, g } >>
 }
 @end lilypond

 @noindent
 Note that the override continues to apply in the first voice of
-the second block of quavers, but not to any of the beams in the
+the second measure of quavers, but not to any of the beams in the
 second voice.

 @subheading force-hshift property



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: separating flags from noteheads in font (issue4273119)


2011/6/11  :

Looks good, but untested.  I'll test it when I can.


Ok. Don't forget to make clean in build/mf - there are still missing
dependencies.

Thanks!


http://codereview.appspot.com/4273119/diff/3001/mf/feta-noteheads.mf
File mf/feta-noteheads.mf (right):

http://codereview.appspot.com/4273119/diff/3001/mf/feta-noteheads.mf#newcode45
mf/feta-noteheads.mf:45: numeric black_notehead_width;
On 2011/06/10 23:12:15, Carl wrote:

Perhaps a comment here to indicate that we have deliberately *not*

used a save

statement for black_notehead_width in order to allow it to be a global

variable

available for other .mf files.  This will help keep people from saying

"Hey --

good practice says to make local variables; let's make it local"


Done.

http://codereview.appspot.com/4273119/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: separating flags from noteheads in font (issue4273119)


with Carl's help, new patch set was uploaded. Now the flags aren't
squished, so it's perhaps ready to go :)

http://codereview.appspot.com/4273119/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: shortened flags: choosing appropriate flag (issue4410049)


On 2011/06/09 08:12:53, MikeSol wrote:

Hey Janek,



All the metafont stuff looks good!  Last time we touched base, I

recall that we

had talked about looking into embedding a lot of this info into the

font - did

that prove to be not doable?  Other than that, I have one comment

below about

the C++ stuff.


I'm working on it with Carl's help, see "parameters in metafont files"
thread.


http://codereview.appspot.com/4410049/diff/16001/lily/stem.cc#newcode612

lily/stem.cc:612:
I remember we worked on a Scheme version of this a while back - I

would suggest

that you replace this bit of code with that.  It'll be easier to

maintain and

debug, and it also hardcodes less values.  There is also a problem

with the

already computed bit - you are assuming that people will not change

fonts midway

through a work.


I have your patch. I remember that i had send you my comments describing
your code, so that you could check whether i understood it correctly.
Did you read it?
Its in "And still cleaner..." thread, message sent on April 25th.

cheers,
Janek

http://codereview.appspot.com/4410049/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: shortened flags: choosing appropriate flag (issue4410049)