Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Keith OHara]

Colin Campbell  shaw.ca> writes:

> New today, for Friday:
> Issue 621:
> Dynamics should avoid cross-staff BarLines (e.g.
>   GrandStaff, PianoStaff etc) - Rietveld 

I should advertise that the patch on this issue includes a Docs change.  
After the patch we no longer need to teach how to un-overlap DynamicText, so I 
replaced it with teaching on how to un-overlap MetronomeMarks

http://codereview.appspot.com/4805054/


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

parser.yy: rearrange to allow more lenient use of music arguments for music functions. (issue4815052)

[dak]

Reviewers: ,

Message:
I should point out that I consider this a merge candidate.  AFAICT, it
passes the regtests.

Description:
parser.yy: rearrange to allow more lenient use of music arguments for
music functions.

This change may be somewhat contentious: it removes a lot of
opportunities for syntax errors by allowing a lot of music functions
to work that did not do so previously.

For one thing, you can use a ly:music? style signature as often as you
want to in all music functions.  There are some cases where it will
only be accepted in "closed form", namely as a music identifier or a
music expression enclosed in { ... } or << ... >>.  Those cases are
before a post-event not belonging to the music argument, or a duration
argument.

Music functions can be used in a number of places with different
semantics, not necessarily the cleanest thing.  When they are used as
post-events and have a music argument last, they will actually try
getting a post-event as that music argument.  What is new (and
probably less than fabulous) that they will instead accept a closed
form music expression.

However, when such a function is used as a primary music event, its
last argument will be a regular music expression anyway.  So it is not
like this argument dichotomy was really all that novel.

In a similar vein, as a chord constituent, a music function will
accept a chord constituent in the place of a prospective last music
argument.

It does not seem overly satisfactory that only the last such component
will be syntactically warped according to the surrounding.  Perhaps
one should use different signatures in the first place.

Suggestions welcome.

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

Affected files:
  M Documentation/extending/programming-interface.itely
  M lily/parser.yy



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

Re: modifying default behaviour of tremolo slashes (issue4636081)

[lemniskata . bernoullego]

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

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

[k-ohara5a5a]

On 2011/07/29 04:31:00, Janek Warchol wrote:

Could you add some comments for rookies like me (the
more, the better)?


Some explanatory comments.  (English takes a lot more space than C.)


http://codereview.appspot.com/4188051/diff/17001/lily/spacing-spanner.cc
File lily/spacing-spanner.cc (right):

http://codereview.appspot.com/4188051/diff/17001/lily/spacing-spanner.cc#newcode526
lily/spacing-spanner.cc:526: Real full_measure_extra_space =
robust_scm2double (l->get_property ("full-measure-extra-space"), 1.0);

I moved the addition of this space (before a single note-column when it
is alone in a measure) earlier because ...

http://codereview.appspot.com/4188051/diff/17001/lily/spacing-spanner.cc#newcode539
lily/spacing-spanner.cc:539: spring = merge_springs (springs);

..when merge_springs() [in spring.cc] combines the desired spacing from
all voices/staves in the system, it lengthens the relaxed-spring
distance of the combined spring enough to give 0.3 space clearance.

The old code first ensured that accidentals were at least 0.3-space away
from the barline, and then added the full-measure-extra-space on top of
that.

http://codereview.appspot.com/4188051/diff/17001/lily/staff-spacing.cc
File lily/staff-spacing.cc (right):

http://codereview.appspot.com/4188051/diff/17001/lily/staff-spacing.cc#newcode208
lily/staff-spacing.cc:208: ideal = max (ideal, fixed);
At an earlier step, while looking up the space to leave after a bar-line
or clef or similar,  the old code made sure that 'fixed' spacing was
enough to leave a bit of clearance.  The 'fixed' distance was intended
to be what gets left if the line is moderately tight, so 'tight'
distance might be a better name.

The problem was that any adjustment to 'fixed' also applied to 'ideal'.
If an accidental would not fit in the tight-spacing gap between a
notehead and barline (they never do) then the 'ideal' distance to the
nothead was increased to the right by nearly the full width of the
accidental.

There is no reason to lengthen a spring when the line has plenty of
room, merely because the space would have been tight if the line were
compressed.  Better to make the spring stiffer, and change the 'ideal'
distance as little as possible.

http://codereview.appspot.com/4188051/diff/17001/lily/staff-spacing.cc#newcode212
lily/staff-spacing.cc:212: ret.set_inverse_compress_strength (max (0.0,
ideal - fixed));
This addition is for issue 1785.  Before 2007 there was only one kind of
strength so one line was enough.

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))
On 2011/07/29 04:31:00, Janek Warchol wrote:

Why this disappeared?


I'm glad you asked.  I /thought/ that I had added this as a hack to
solve issue 1229, which hack would not be necessary if space-alist works
correctly, but I don't see it in my patch.
Next time I have linux up I'll use git-blame to learn why this was
added, and put it back if the reason still holds.

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

___
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)

[lemniskata . bernoullego]

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: Postscript printer errors with rounded barlines?

[Jan Warchoł]

2011/7/27 Han-Wen Nienhuys :
> On Wed, Jul 27, 2011 at 3:23 PM, Jan Warchoł
>  wrote:
>
>>> I think this is an other issue.  Due to rounding, PDF viewers can err
>>> the placement of the barline by a pixel. This is insolvable, as there
>>> is no way to hint that the barline should coincide with the staffline,
>>> yet we need to go the end of the barline to get the correct effect in
>>> the corners in staves.
>>
>> I'd accept this if it were not for the fact that Finale seems to
>> handle this perfectly.  I've never experienced any sticking out
>> barlines in Finale pdfs, neither on screen nor in print (i can send
>> you some if you want).  Also, the thickness of the stems and barlines
>> is consistent in Finale pdfs (i.e. it looks like second image from
>> here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00076.html
>> while Lily output looks like first one).
>> I'd say that the fact that Finale does something this basic better
>> than LilyPond is a serious insult to us, given how much Finale sucks
>> in these matters (for example in flag attachment, see attached).
>
> You can make the problem disappear by
>
> - hard coding the output to a certain resolution

Umm, i don't understand what you mean...

> - making the bar go to the middle of the staffline, rather than the outside.

I have a patch doing this:
http://codereview.appspot.com/4809057

> both have disadvantages. (what does finale's barline at the end of a
> staff look like?)

Sharp and pointy, example attached.

cheers,
Janek


Canticorum.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: some comments do not appear in the tracker page

[Janek Warchoł]

James,

2011/7/27 James Lowe :
> Janek
>
> )On Behalf Of Janek Warchol:
> )there is a problem with comments in the tracker.  At least 2 comments
> )didn't make it to the "changing G clef" issue page:
> )- Trevor's comment from July 26th, containing sentence "The G clef font
> )was changed 18 months or so ago by Carl without all this fuss"
> )- Carls comment, perhaps from July 25th, containing sentence "This
> )proposal was based on Graham's assertion that 2.16 is 10 days away from
> )release"
>
> Are these messages you are missing on the tracker itself (as opposed to 
> someone just replying to the email that the tracker generates)?

Umm, i don't understand what you mean...

When you go to http://code.google.com/p/lilypond/issues/detail?id=1752
, do you see any message sent by Trevor? For example
"I agree.  LilyPond has many glyphs.  If we start using
overrides to select glyphs with minor differences where
might it end?"
?
I don't see it there and it didn't appear in my e-mail account.  The
only place where i can see it is bug- archives:
http://lists.gnu.org/archive/html/bug-lilypond/2011-07/msg00375.html
... oh well, i found it.  I've disabled receiving e-mails from
bug-lilypond, silly me.  I remember now that i did this a long time
ago as they seemed irrelevant to me, and i never noticed the
difference...
Ugh  .
Still, i think that it'd be better if every message related to a
tracker issue appeared as a comment in the tracker.

cheers,
Janek

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

Re: Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)

[Keith OHara]

On Thu, 28 Jul 2011 05:46:29 -0700,  wrote:


Message:
On 2011/07/26 02:17:28, Keith wrote:

I like it, although I can still get the error if I put a new voice in

the quoted

expression like this:
   quoteMe = \relative c' \new Voice {


Yeah, but then we have a general problem: Which voice do we want to
quote?


I would not expect LilyPond to divine the answer to that question,
but it would be nice to avoid exiting the program with
 ERROR: Value out of range: 0



It is interesting, in a good way, how it works with
   << {c4 c} \\ {g g} >>
divisi parts if both parts have the same rhythm,
but I would not encourage that we try to guarantee nor advertise that.


The << \\ >> construct uses two new voices, so none of the notes will be
quoted.



But somehow your patch quotes them both, showing as a << c g >> in the cue 
voice.


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

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

[lemniskata . bernoullego]

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

auto numbering footnote checkin doesn't play with \null and \musicglyph

[James Lowe]

Mike,

I *think* your recent checkin did something to your original \footnote[Grob] 
code because taking a snippet from my example in my in-progress doc patch

\version "2.15.6"

 #(set-default-paper-size "a6")

\book {
  \relative c' {
   c1
\breathe
\footnoteGrob #'BreathingSign #'(1 . 1)
\markup { \musicglyph #"rests.4" }
\markup { \null }
  }
}

Worked fine.

Now it prints the numeral '1' all over the place actually. If you change \null 
to " ", then it goes away but I get a number with no footnote. It also seems to 
ignore the glyph used in a markup.

My original intention in my doc patch was to show how to have a 'footnoteGrob 
markup without a footnote (and also show how you can add space between the 
copyright and the last footnote), Neil suggested I use \null instead of " " 
which did the same thing, until now.

regards

James

weird.pdf
Description: weird.pdf


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

Re: New engraver for braces (issue4807053)

[bordage . bertrand]

I updated the patch to work on the latest git HEAD.

After doing a clean regtest comparison (git clean -fxd, config, make,
make test-baseline, make check), I don't see anything.
The logs' names show this is due to Mike's last commits.

Regards,
Bertrand

http://codereview.appspot.com/4807053/

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

Re: font: change breve vertical lines (issue4748044)

[lemniskata . bernoullego]

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 : little scheme problem (ly-> xml )

[Gilles]

(define function-value-list
   '((duration  . ( ,ly:duration-log )) 
 (step   . (,ly:pitch-notename ))
 (octave . (,ly:pitch-octave ))
 (test   . (,display 



At the beginning of line 2, replace the apostrophe ' by `
(a semiquote in scheme)
http://www.gnu.org/software/guile/manual/guile.html#Expression-Syntax

(define function-value-list
 `((duration  . ( ,ly:duration-log ))   etc ...


Gilles


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

Re: New engraver for braces (issue4807053)

[pkx166h]

Make is ok, but reg test gives me a few warnings on some reg tests.

--snip--


/home/jlowe/lilypond-git/input/regression/footnote-auto-numbering.log   

@@ -9,28 +9,28 @@
 Finding the ideal number of pages...
 Fitting music on 1 or 2 pages...
 Drawing systems...
-programming error: Improbable offset for stencil:
823787934458423451582464.00 staff space
+programming error: Improbable offset for stencil:
68178455185675213864960.00 staff space
 Setting to zero.
 continuing, cross fingers
-programming error: Improbable offset for stencil:
823787934458423451582464.00 staff space
+programming error: Improbable offset for stencil:
68178455185675213864960.00 staff space
 Setting to zero.
 continuing, cross fingers
-programming error: Improbable offset for stencil:
823787934458423451582464.00 staff space
+programming error: Improbable offset for stencil:
68178455185675213864960.00 staff space
 Setting to zero.

etc.

-snip-

../input/regression/footnote-auto-numbering.log

../input/regression/footnote-auto-numbering-page-reset.log

../input/regression/footnote-footer-padding

http://codereview.appspot.com/4807053/

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

Re: Doc: NR Added new Node for Footnotes (issue4751045)

[pkx166h]

note from Mike

--snip--

I just pushed a patch for automatic footnotes.  Everything you need to
know about them exists in the two new regtests
(233aad0ba9781e43424c4e77a859e42b660210e6).  The most important thing to
note is that, if people want to use non-automatic footnotes, they must
now add footnote-auto-numbering=##f in the paper block.  Otherwise, Lily
will attempt to do auto numbering and erase whatever numbering scheme
the person is manually using.

--snip--



http://codereview.appspot.com/4751045/

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

GOP-PROP 7: Developers as resources

[Graham Percival]

http://lilypond.org/~graham/gop/gop_7.html

Recent discussions have prompted me to clarify this.


** Proposal summary

How should treat+view developers? I see three main contenders:

   1. Independent volunteers: each person does whatever they want,
whenever they want. We have busy careers and lives; we make no
expectations of action from anybody (with the exception of 6
people in “Meister” positions).
   2. Human resources: developers are members of a team; we can
build better software with more coordination. Developers will be
assigned bugs to fix, features to implement, and patches to
review.
   3. Mixed: we form 1 or 2 teams of developers, plus indepedents.
Developers are still free to do whatever they want whenever they
want as independents, but they can also sign up for a team for X
hours a week. For those X hours, they will be assigned bugs to
fix, features to implement, and patches to review. 


** Rationale

I have historically been very vocal about treating developers at
“independent volunteers”, but some recent discussions are making
me wonder if that’s the best way to go.

Our policy on this topic will influence many upcoming discussions.


** Amateur orchestra

I deliberately chose the loaded term “human resources” to get our
immediate distaste out of the way. Here’s the positive spin on
that idea: I shall describe the workings of the (Vancouver) “West
Coast Symphony Orchestra” (at least when I was playing with them,
back in 2002-2006).

This orchestras is the best amateur orchestra in Vancouver; it
is better than most university student orchetras. Most of its
members are doctors, engineers, or lawyers, and the average age is
between like 40-50. As you would expect, they have busy careers,
growing families, but still love to play music.

There are 5-6 weekly rehearsals for each concert. The list of
performers for a particular concert is relatively fluid; there’s
up to 30% fluctuation in the list of performers. A week or two
before each set of rehearsals start, a list is passed around where
people sign up for the concert or not.

There is no discouragement from missing a concert – members
know that they all have busy lives, and if there is a big deadline
at work or a family vacation during a rehearsal period, they
simply do not sign up for that concert. However, if you do sign up
for a concert, then you are normally only allowed to miss one
rehearsal. 

Orchestras are particularly interesting because they involve a
voluntary surrender of freedom. When the conductor indicates a
tempo, you don’t start playing your part however you want; you
follow his tempo. If the conductor tells your section to play
quieter so that the soloist can be heard, you don’t start arguing.
You follow his directions, even if you think he’s wrong – not
because you’re getting paid to do so, but because you trust that
in the long run, having a single authority controlling 80
musicians allows them to produce better music than 80 musicians
all exercising their independent judgement.


** Problems with independent judgement

The orchestra idea (or choir, or dance troup, or any volunteer
activity which involves following somebody else’s orders) could be
benefitial in lilypond.

We’ve seen a certain amount of friction lately with reviews. Not
enough reviews; reviews are too superficial; feeling uncertain
about reviewing code that’s not your speciality.

To take one specific case by the bull’s horns: David has
identified a few problems in an old commit. We’ve noted a few
problems, such as non-experts reviewing the patch (which is still
fantastically better than nobody reviewing the patch!). But David
is also interested in the parser – which is an area of lilypond
that has even fewer experts, and even less interest, than the old
patch that introduced a few problems.

If we had a central authority leading a team (or teams) of
developers – or at least, leading developers for X hours a week –
then we could “enforce” reviews. Maybe July-August would be
directed towards the graphical display of rhythms. That team would
dissect any patch for beaming, drawing longas, etc; any patch to
the parser would be ignored (at least, ignored during the X hours
of team work). But perhaps the team leader would decide to look at
parser stuff in November. That’s not ideal for David, since he’s
interested in working on that stuff now... but perhaps he’d be
willing to wait until Nov (or Oct), so that at least when it
happens, there will be a serious discussion about those problems
and serious review of those patches.


** Bottom line

We’re not going to pick option 2 “treat developers like human
resources”. I’m mainly wondering if there’s enough interest in
option 3 “mixed” to make it worth doing.

Note that you don’t need to spend all your lilypond time on the
team-based approach of the “mixed” option. You could sign up for 5
hours of “team work” each week, but still spend another 5 hours on
your own lilypond work, submitting patches and s

Re: Current state of automatic footnotes. (issue4580041)

[mtsolo]

Many thanks to everyone for their help on this.

Pushed as 233aad0ba9781e43424c4e77a859e42b660210e6.

Cheers,
MS

http://codereview.appspot.com/4580041/

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[bordage . bertrand]

It doesn't need to be ordered.
It can have holes, but there's a small issue with this for now:
Church rests are only looking for maximum and minimum values. You can
therefore find longas in a church rest if you set usable-duration-logs
to '(0 -1 -3).
I don't know whether it's better to keep this system or to stick to
usable-duration-logs.
This would be logical to stick to the list, but church rests are
something special that doesn't behave the same way than uncompressed
multi-measure rests.  Maybe a separated list for church rests would be
the best solution...

Thanks,
Bertrand

http://codereview.appspot.com/4536068/

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

Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Colin Campbell]

On 11-07-27 10:59 PM, Graham Percival wrote:

On Wed, Jul 27, 2011 at 08:04:21PM -0600, Colin Campbell wrote:

The list of patches still not dealt with is rather alarming: is it because
devels are on holiday, am I missing the closed or fixed tags in Rietveld and
Google Code?  How can I help you folk keep this moving?

You could check the git changelog (either in gitk, or on the web)
to make sure that nobody pushed something without marking it
fixed.  Then send private emails to people reminding them to push,
or to send final patches to me if they don't have push ability.

Private emails always get more attention.  Yes, it adds another 30
minutes to your job, but with the looming Aug 1 deadline before
existing C++ patches get awkward, I think it's worth the effort.

Cheers,
- Graham




Good points, Graham, and I'll try to do that.

Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



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

Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Colin Campbell]

On 11-07-28 12:48 AM, m...@apollinemike.com wrote:

On Jul 28, 2011, at 4:04 AM, Colin Campbell wrote:


New today, for Friday:

Issue 621 : 
Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, 
PianoStaff etc) - Rietveld



Countdown done, but still open/not marked fixed:
From Wednesday July 27

Issue 732 : 
Alignment problems when vertically stacking horizontally centered 
stencils. - Rietveld Issue 4798050 
: Fix 732: center-column 
ignored left half of stencil extent -> collision with previous stencil
Issue  : 
Allow manual directions on dynamics to break alignment spanner 
automatically - Rietveld Issue 4810048 
: Fix : Break dynamic 
line spanner if different direction is explicitly given
Issue 1730 : 
Documentation for lilypond-windows.exe and -dgui option - Rietveld 
Issue 4806050 : Doc: Usage - 
new option for lilypond-book



And a couple of Rietveld-only patches:
  Issue 4668045 : Fixes error 
for tuplet bracket direction calculation when tuplets contain rests.
Issue 4639075 : Moves tuplet 
numbers outside staff with their brackets.
  Issue 4580041 : Current 
state of automatic footnotes.




  Issue 1433 
: 
\breakDynamicSpan breaks with \break ("bounds of spanner are 
invalid") - Rietveld Issue 4630070 
: Fix issues 1259 and 1433 
(\breakDynamicSpan and a spanner's style=#'none over a line break)
  Issue 1259 
: 
DynamicTextSpanner #'style = #'none doesn't work over \break


The list of patches still not dealt with is rather alarming: is it 
because devels are on holiday, am I missing the closed or fixed tags 
in Rietveld and Google Code?  How can I help you folk keep this moving?





Hey Colin,

Sorry for the delay!  I'll take care of a large portion of my backlog 
today (I run an extra regtest before pushing, which slows me down a bit).


Cheers,
MS



No problem, Mike: extra testing is always in order.  Many's the time I 
wished I'd checked the order first: ready, fire, aim or  . . .


Thanks for the effort!

Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 

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

Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Colin Campbell]

On 11-07-28 01:16 AM, Reinhold Kainhofer wrote:

On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell  wrote:

Countdown done, but still open/not marked fixed:
From Wednesday July 27
Issue 732: Alignment problems when vertically stacking horizontally centered
stencils.
Issue : Allow manual directions on dynamics to break alignment spanner
automatically
  Issue 1433: \breakDynamicSpan breaks with \break ("bounds of spanner are 
invalid")
  Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over \break

The list of patches still not dealt with is rather alarming: is it
because devels are on holiday,

Those four patches quoted above are mine, and I'm currently at vacation at home 
with my parents, so I simply don't find enough time to deal with them right 
now. I'll fix and close them in the next few days.
Cheers,
Reinhold




No worries, Reinhold.  Thanks for your hard work, and I see you've 
already pushed them.  Great to get that group around the dynamic spanner 
off this list!


Enjoy the rest of the vacation, and sorry for the nagging.

Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 



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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[Benkő Pál]

hi Bertrand,

I started at the patch but it's quite difficult for now,
I hope I'll have enough time in the evening.  till then
could you tell me whether usable-duration-logs is
ordered?  is it a range or can it have holes?

thanks,
p

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

Re: Fix 1214: cueDuring and quoteDuring should also quote voices that create subvoices (issue4816044)

[reinhold . kainhofer]

Reviewers: J_lowe, Keith,

Message:
On 2011/07/26 02:17:28, Keith wrote:

I like it, although I can still get the error if I put a new voice in

the quoted

expression like this:
   quoteMe = \relative c' \new Voice {


Yeah, but then we have a general problem: Which voice do we want to
quote?



http://codereview.appspot.com/4816044/diff/3001/input/regression/quote-during-subvoice.ly#newcode12

input/regression/quote-during-subvoice.ly:12: \new Voice {
You might keep the main voice going in parallel
<< { c4 c }
\new Voice { g4 g } >>
to ensure that the patch continues to work (as it does now) to quote

an

instrument that is itself quoting third. (I've actually wanted to to

this, for

taking cues, in a couple situations.)


Yes, good idea, too.


It is interesting, in a good way, how it works with
   << {c4 c} \\ {g g} >>
divisi parts if both parts have the same rhythm,
but I would not encourage that we try to guarantee nor advertise that.


The << \\ >> construct uses two new voices, so none of the notes will be
quoted.
Cheers,
Reinhold



Description:
Fix 1214: cueDuring and quoteDuring should also quote voices that create
subvoices

If a voice was quoted that created a subvoice, add-quotable wrongly
selected
only that subvoice for quoting rather than the original voice.

The proper fix is to correctly use the assoc list returned by
recording-group-emulate. We need to hand it a proper unique voice name
and can then extract the events for just this voice, no matter which
other
voices are created.

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

Affected files:
  A input/regression/quote-during-subvoice.ly
  M scm/part-combiner.scm


Index: input/regression/quote-during-subvoice.ly
diff --git a/input/regression/quote-during-subvoice.ly  
b/input/regression/quote-during-subvoice.ly

new file mode 100644
index  
..f8d61e34923683a2b0fffeaf654cf917360e7ce3

--- /dev/null
+++ b/input/regression/quote-during-subvoice.ly
@@ -0,0 +1,21 @@
+\version "2.15.6"
+
+\header {
+  texidoc = "@code{\\quoteDuring} and @code{\\cueDuring} shall properly  
quote

+voices that create a sub-voice. The sub-voice will not be quoted, though.
+"
+}
+
+
+quoteMe = \relative c' {
+  c4 c
+  \new Voice {
+c4 c
+  }
+}
+\addQuote quoteMe \quoteMe
+
+\relative c'' {
+  c4 \cueDuring #"quoteMe" #DOWN { r4 } % <- show a cue note from quoteMe
+  c4 \cueDuring #"quoteMe" #DOWN { r4 } % <- no cue note due to sub-voice
+}
Index: scm/part-combiner.scm
diff --git a/scm/part-combiner.scm b/scm/part-combiner.scm
index  
0e72ebe2a057eef1f4284e9c4d69fa3c4e20ee94..54f9ea4a57aeefe4a3389c6a779e85cc06d78c1d  
100644

--- a/scm/part-combiner.scm
+++ b/scm/part-combiner.scm
@@ -571,10 +571,18 @@ the mark when there are no spanners active.

 (define-public (add-quotable parser name mus)
   (let* ((tab (eval 'musicQuotes (current-module)))
-(context-list (recording-group-emulate (context-spec-music mus 'Voice)
-   (ly:parser-lookup parser 
'partCombineListener
-(if (pair? context-list)
-   (hash-set! tab name
-  ;; cdr : skip name string
-  (list->vector (reverse! (cdar context-list)
-  '()))
+ ;; If a Voice is passed, use its contents:
+ (contents (if (equal? (ly:music-property  
mus 'name) 'ContextSpeccedMusic)

+   (ly:music-property mus 'element)
+   mus))
+ (voicename (get-next-unique-voice-name))
+ ;; recording-group-emulate returns an assoc list, so hand it a
+ ;; proper unique context name and extract that key:
+ (context-list (recording-group-emulate (context-spec-music  
contents 'Voice voicename)
+(ly:parser-lookup  
parser 'partCombineListener)))

+ (quote-contents (if (assoc voicename context-list)
+ (assoc-get voicename context-list)
+ '(
+
+(if quote-contents
+(hash-set! tab name (list->vector (reverse!  
quote-contents '()))




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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[bordage . bertrand]

> I should have write "2 << (-i + 1)" instead of "/2"...



the +1 multiplies by 2, not divides.


Whoops, I meant -(i + 1)...


perhaps the best would be 1 << -i.


Thanks.
When I told you I never understood "<<", I wasn't kidding!
An update will follow this comment.

Bertrand

http://codereview.appspot.com/4536068/

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[Benkő Pál]

> To be honest, I never understood well how this bitset operator works.

adds trailing zeros in binary.

> What I see is that "2 << -i" gives the same result than "2^(-i+1)".
> I should have write "2 << (-i + 1)" instead of "/2"...

the +1 multiplies by 2, not divides.

perhaps the best would be 1 << -i.

now I'll really take a look at the actual patch...

p

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[bordage . bertrand]

http://codereview.appspot.com/4536068/diff/37002/lily/multi-measure-rest.cc#newcode241

lily/multi-measure-rest.cc:241: length = (2 << -i) / 2;
The division by 2 changes the result.  Not that I understand too well

what it is

supposed to be doing.


To be honest, I never understood well how this bitset operator works.
What I see is that "2 << -i" gives the same result than "2^(-i+1)".
I should have write "2 << (-i + 1)" instead of "/2"...

Besides this, I would like to remove these ugly "if"s I added yesterday,
but I don't see a better human-readable solution.

Bertrand

http://codereview.appspot.com/4536068/

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

New engraver for braces (issue4807053)

[bordage . bertrand]

Reviewers: ,

Message:
Hi!

This patchs allows to add braces the same way as arpeggios.
Very useful for complex organ music.
Check this out, there is several examples:
http://imslp.org/wiki/12_Pi%C3%A8ces_pour_Orgue_(Gigout,_Eug%C3%A8ne)

For the moment, the new engraver is a clone of Arpeggio_engraver.
But I would like to add a command to attach text directly to braces (see
IMSLP's
score). Since there's many cases for the text attachment points, I think
a new
engraver is required.

Done with Mike's help.

The regression test is temporary.

Regards,
Bertrand

PS: Li Jie Wong requested this last year :
http://lists.gnu.org/archive/html/lilypond-user/2010-11/msg00361.html



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

Affected files:
  A input/regression/braces.ly
  M lily/arpeggio.cc
  A lily/brace-engraver.cc
  M lily/include/arpeggio.hh
  M lily/span-arpeggio-engraver.cc
  A lily/span-brace-engraver.cc
  M ly/engraver-init.ly
  M ly/property-init.ly
  M scm/define-context-properties.scm
  M scm/define-event-classes.scm
  M scm/define-grob-interfaces.scm
  M scm/define-grob-properties.scm
  M scm/define-grobs.scm
  M scm/define-music-display-methods.scm
  M scm/define-music-types.scm
  M scm/safe-lily.scm



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

Re : little scheme problem (ly-> xml )

[bigcab]

Le 28/07/2011 13:36, lilypond-devel-requ...@gnu.org a écrit :

Send lilypond-devel mailing list submissions to
lilypond-devel@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/lilypond-devel
or, via email, send a message with subject or body 'help' to
lilypond-devel-requ...@gnu.org

You can reach the person managing the list at
lilypond-devel-ow...@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of lilypond-devel digest..."


Today's Topics:

1. Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
   (Reinhold Kainhofer)
2. Re: Fixes error for tuplet bracket direction calculation when
   tuplets  contain rests. (issue4668045) (mts...@gmail.com)
3. RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
   (James Lowe)
4. little scheme problem (convert ly ->  xml) (bigcab)
5. Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
   (m...@apollinemike.com)
6. Re: Moves tuplet numbers outside staff with their brackets.
   (issue4639075) (mts...@gmail.com)
7. Re: little scheme problem (convert ly ->  xml) (Jan Nieuwenhuizen)
8. Re: little scheme problem (convert ly ->  xml) (David Kastrup)
9. Re: review process not working (Reinhold Kainhofer)
   10. Re: review process not working (David Kastrup)


--

Message: 1
Date: Thu, 28 Jul 2011 09:16:28 +0200
From: Reinhold Kainhofer
To: Colin Campbell, Devel
Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
Message-ID:<1311837388.7156.2.camel@Nokia-N900>
Content-Type: text/plain; charset=utf-8

On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell  wrote:

Countdown done, but still open/not marked fixed:
?  From Wednesday July 27
Issue 732: Alignment problems when vertically stacking horizontally centered
stencils.
Issue : Allow manual directions on dynamics to break alignment spanner
automatically
?Issue 1433: \breakDynamicSpan breaks with \break ("bounds of spanner are 
invalid")
?Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over \break

The list of patches still not dealt with is rather alarming: is it
because devels are on holiday,

Those four patches quoted above are mine, and I'm currently at vacation at home 
with my parents, so I simply don't find enough time to deal with them right 
now. I'll fix and close them in the next few days.
Cheers,
Reinhold



--

Message: 2
Date: Thu, 28 Jul 2011 07:59:06 +
From: mts...@gmail.com
To: james.l...@datacore.com, hanw...@gmail.com, pkx1...@gmail.com,
m...@apollinemike.com, k-ohara5...@oco.net, n.putt...@gmail.com
Cc: re...@codereview.appspotmail.com, lilypond-devel@gnu.org
Subject: Re: Fixes error for tuplet bracket direction calculation when
tuplets contain rests. (issue4668045)
Message-ID:<20cf3011dfc30721b004a91c8...@google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

Pushed as eed6f105c0b478572ec2b8fa93e1f96c0c5869ba.

Cheers,
MS

http://codereview.appspot.com/4668045/



--

Message: 3
Date: Thu, 28 Jul 2011 08:07:08 +
From: James Lowe
To: Reinhold Kainhofer, Colin Campbell
, Devel
Subject: RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
Message-ID:



Content-Type: text/plain; charset="utf-8"

Hello,

)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Reinhold Kainhofer
)Sent: 28 July 2011 08:16
)To: Colin Campbell; Devel
)Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
)
)On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell
)wrote:
)>  Countdown done, but still open/not marked fixed:
)>?  From Wednesday July 27
)>  Issue 732: Alignment problems when vertically stacking horizontally
)>centered  stencils.
)>  Issue : Allow manual directions on dynamics to break alignment
)>spanner  automatically
)>?Issue 1433: \breakDynamicSpan breaks with \break ("bounds of spanner
)>are invalid")
)>?Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over
)>\break
)>
)>  The list of patches still not dealt with is rather alarming: is it
)>  because devels are on holiday,
)
)Those four patches quoted above are mine, and I'm currently at vacation
)at home with my parents, so I simply don't find enough time to deal with
)them right now. I'll fix and close them in the next few days.
)Cheers,
)Reinhold
)
---

I also keep half an eye on Rietveld issues being updated in the emails and 
Trackers not - as the patches are on Rietveld it is more than likely a dev will 
do one but forget the other. So I often step in and cut/paste the relevant 
comment on the Rietveld and update the Tracker.

Until we get a single place to put issues and Patches I can't see 

RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[James Lowe]

Hello,

)-Original Message-
)From: m...@apollinemike.com [mailto:m...@apollinemike.com]
)Sent: 28 July 2011 09:16
)To: James Lowe
)Cc: Reinhold Kainhofer; Colin Campbell; Devel
)Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
)Importance: Low
)
)On Jul 28, 2011, at 10:07 AM, James Lowe wrote:
)
)> PA to Mike Solomon
)
):)
)Even with my new virtual box, I am sometimes forgetting to take certain
)steps to get a clean baseline (i.e. forgetting to commit changes before
)deleting a branch, which leaves a set of files in my new branch, which
)then gets compiled with a patch, etc.).  That has gotten better in the past
)few days, but I still make mistakes (like the slur stuff).  Your regtest and
)admin help is very appreciated!
)
)Cheers,
)MS

Mike, depending on your Host machine you can use snapshot of VBOX quite 
effectively, to snapshot a point where you KNOW you have a clean build and even 
create snaps of different stages of your dev. I use it a lot because I get 
confused with git stashing and popping, but also to save me having to keep 
making a clean make test-baseline (only because it is much more sure to go back 
to a snap than run the 'clean' make commands).

James


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

Re: review process not working

[David Kastrup]

Reinhold Kainhofer  writes:

> And with the patch reviews and the patch countdown, at least we get
> some feedback now. A while ago it used to be luck if you posted a
> patch to the devel list and got one response eventually.

Well, that's what I experience with my syntax extensions.  I'm currently
down to eliminating some reduce/reduce conflicts because I am not happy
with the semantics of the last patch version (which received no feedback
like its predecessors), and then am likely to document and commit it.

What worked before will continue to work except for some hypothetical
borderline cases (not to be found in regtests) which you need to rewrite
into something quite more convenient.

The main benefit for the average Lilyponder will likely be that there
will actually be documentation.  The previous semantics were awkward and
undocumented.

So in my case, the review process tends to do nothing.  Could be worse,
but likely nobody except myself would know the difference.  In the case
I brought up here, the review process did a lot, but too superficially.
Of those cases, the second one is much more likely to get an ISO
certification for proper process.

I don't feel good about either.

-- 
David Kastrup

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

Re: review process not working

[Reinhold Kainhofer]

Am Dienstag, 26. Juli 2011, 19:43:26 schrieb David Kastrup:
> Reinhold Kainhofer  writes:
> > So, it seems the only one who is aware of those rounding problems is
> > David. The question then is, why didn't David do a review of the patch
> > and now complains that the process is not working?
> 
> Come on.

Yes, I didn't intend it to sound like an ad-hominem attack. Sorry for that.

One important thing with code reviews is that either one perfect reviewer 
(which doesn't exist, of course) looks at it, or many different eyes look at a 
patch and might observe problems. Most developers - me included - simply do 
not do enough code reviews. The reason is mostly that we all think that we 
don't know enough about the code or the area that the patch is about.

Rather, we should still try to look at and understand those patches, because 
we might also spot some logic errors or style errors, even if we don t know 
anything about that area.

Anyway, code review is no guarantee for perfect and fault-less patches. 
Rather, it minimizes the chance of bad code going into lilypond, and it 
increases the chance that problems are found. But 100% can never be achieved.

And with the patch reviews and the patch countdown, at least we get some 
feedback now. A while ago it used to be luck if you posted a patch to the 
devel list and got one response eventually.

Cheers,
Reinhold
-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

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

Re: little scheme problem (convert ly -> xml)

[David Kastrup]

Jan Nieuwenhuizen  writes:

> bigcab writes:
>
>> (define function-value-list
>> (('duration  . ((lambda(x) (ly:duration-log x
>
> What are you trying to achieve by doing (lambda (x) (foo x))?
>
>> ('step   . ((lambda(x) (ly:pitch-notename x
>> ('test   . ((lambda(x) (begin (display "salut :")
>> (display x) (display ".\n")
>> ('octave . ((lambda(x) (ly:pitch-octave x))
>
> You probably want something like
>
>(define function-value-list
>   `((duration . (,ly:duration-log))
> (step . (,ly:pitch-notename))
> (test . (,lambda (x) (begin (display "salut: ") ...)))
> ...))

The begin form seems sort of pointless as a top level part in lambda.

-- 
David Kastrup


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

Re: little scheme problem (convert ly -> xml)

[Jan Nieuwenhuizen]

bigcab writes:

> (define function-value-list
> (('duration  . ((lambda(x) (ly:duration-log x

What are you trying to achieve by doing (lambda (x) (foo x))?

> ('step   . ((lambda(x) (ly:pitch-notename x
> ('test   . ((lambda(x) (begin (display "salut :")
> (display x) (display ".\n")
> ('octave . ((lambda(x) (ly:pitch-octave x))

You probably want something like

   (define function-value-list
  `((duration . (,ly:duration-log))
(step . (,ly:pitch-notename))
(test . (,lambda (x) (begin (display "salut: ") ...)))
...))


Jan.

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

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

Re: Moves tuplet numbers outside staff with their brackets. (issue4639075)

[mtsolo]

Pushed as 72210831b0366cb7c1f7009ba99a56538d68a7e5.

Cheers,
MS

http://codereview.appspot.com/4639075/

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

Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[m...@apollinemike.com]

On Jul 28, 2011, at 10:07 AM, James Lowe wrote:

> PA to Mike Solomon

:)
Even with my new virtual box, I am sometimes forgetting to take certain steps 
to get a clean baseline (i.e. forgetting to commit changes before deleting a 
branch, which leaves a set of files in my new branch, which then gets compiled 
with a patch, etc.).  That has gotten better in the past few days, but I still 
make mistakes (like the slur stuff).  Your regtest and admin help is very 
appreciated!

Cheers,
MS


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

little scheme problem (convert ly -> xml)

[bigcab]

Hi,


As you know , I have started coding the ly-> xml in scheme,
but  as i want to make the code easier to read, I started to create a list
of callback to retrieve information for example
so I wrote this (for example):

;; once you retrived the good object you just have to extract its value
;; functions to retrieve the value of duration/step/octave
(define function-value-list
(('duration  . ((lambda(x) (ly:duration-log x
('step   . ((lambda(x) (ly:pitch-notename x
('test   . ((lambda(x) (begin (display "salut :") 
(display x) (display ".\n")

('octave . ((lambda(x) (ly:pitch-octave x))

;; return false if value is not found
(define (get_value music name )
(if (assq name function-value-list)
(let (fun (car(assq name function-value-list)))
(fun music))
(#f)))

however , it does not seem to work , because is always says Wrong type 
to apply: duration
even though I never called the function yet... if i am executing it 
inside a lilypond file


i get this Unbound variable: function-value-list

so I begin to think it is impossible to create a list containing, is it ?

if so, i will have to create each function one by one, so it would be 
longer and more difficult to edit ...




Thanks very much

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

RE: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[James Lowe]

Hello,

)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Reinhold Kainhofer
)Sent: 28 July 2011 08:16
)To: Colin Campbell; Devel
)Subject: Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29
)
)On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell 
)wrote:
)> Countdown done, but still open/not marked fixed:
)>   From Wednesday July 27
)> Issue 732: Alignment problems when vertically stacking horizontally
)>centered  stencils.
)> Issue : Allow manual directions on dynamics to break alignment
)>spanner  automatically
)> Issue 1433: \breakDynamicSpan breaks with \break ("bounds of spanner
)>are invalid")
)> Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over
)>\break
)>
)> The list of patches still not dealt with is rather alarming: is it
)> because devels are on holiday,
)
)Those four patches quoted above are mine, and I'm currently at vacation
)at home with my parents, so I simply don't find enough time to deal with
)them right now. I'll fix and close them in the next few days.
)Cheers,
)Reinhold
)
---

I also keep half an eye on Rietveld issues being updated in the emails and 
Trackers not - as the patches are on Rietveld it is more than likely a dev will 
do one but forget the other. So I often step in and cut/paste the relevant 
comment on the Rietveld and update the Tracker.

Until we get a single place to put issues and Patches I can't see this really 
changing and as has been said before, it is more important to keep the Devs 
slaving^H^H^H^H^H^H^H working away fixing and improving LP than worrying *too* 
much about the admin.

James
PA to Mike Solomon
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixes error for tuplet bracket direction calculation when tuplets contain rests. (issue4668045)

[mtsolo]

Pushed as eed6f105c0b478572ec2b8fa93e1f96c0c5869ba.

Cheers,
MS

http://codereview.appspot.com/4668045/

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

Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Reinhold Kainhofer]

On Do., 28. Jul. 2011 04:04:21 CEST, Colin Campbell  wrote:
> Countdown done, but still open/not marked fixed:
>   From Wednesday July 27
> Issue 732: Alignment problems when vertically stacking horizontally centered 
> stencils.
> Issue : Allow manual directions on dynamics to break alignment spanner 
> automatically
> Issue 1433: \breakDynamicSpan breaks with \break ("bounds of spanner are 
>invalid")
> Issue 1259: DynamicTextSpanner #'style = #'none doesn't work over \break
> 
> The list of patches still not dealt with is rather alarming: is it 
> because devels are on holiday, 

Those four patches quoted above are mine, and I'm currently at vacation at home 
with my parents, so I simply don't find enough time to deal with them right 
now. I'll fix and close them in the next few days.
Cheers,
Reinhold

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