Re: Google Summer of Code - should we participate?
On Wed, Feb 23, 2011 at 10:59:46AM -0300, Han-Wen Nienhuys wrote: > 2011/2/23 Janek Warchoł : > > should we participate in Google Summer of Code this year? (it's about > > students from all over the world who work on Open Source projects > > during summer holidays and Google pays them, website: > > http://www.google-melange.com/) > > DEADLINE of applicating: March 11. > > What do you think? > > The FSF could act as organization, but the last time we looked at > this, we lacked skilled mentors with enough time. I have to agree. :( If the mentors project had taken off a year ago, or if we'd already resolved most of the GOP policy decisions, then we'd have a good chance at this. But as things are, I think we need to say "next year". Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 13.51 regtests
Francisco Vila wrote Wednesday, February 23, 2011 6:38 PM
2011/2/23 Phil Holmes :
Another change I don't understand.
Although I don't understand much about regtests, this difference
could
show that printing order of objects in the same layer (with the
same
value of the layer property) is indeterminate, therefore you could
try
again and obtain a different result. NR 5.4.7 "Visibility of
objects"
under "Painting objets white".
That's exactly the cause. Perhaps the reg test should
be changed to set 'layer explicitly on the grobs involved
so the test is reliably reproducible, like this:
\header {
texidoc = "The whiteout command underlays a white box under a
markup. If grobs other than staff lines are involved their
@code{layer} property should be set explicitly, since the
order of processing grobs with the same value of @code{layer}
is not reliably reproducible.
"
}
\version "2.12.0"
\paper
{
ragged-right = ##t
}
\relative c'' {
\override TextScript #'extra-offset = #'(2 . 3)
\override Stem #'layer = #3
c4-\markup { \whiteout \pad-markup #0.5 foo } c
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pdfTex failure
Graham Percival wrote Wednesday, February 23, 2011 2:23 AM On Tue, Feb 22, 2011 at 04:33:34PM +, James Lowe wrote: Hello )After increasing save size to 1 the doc build completed perfectly, so )all is OK at the moment, but as I hacked a file which says "don't hack this" )I guess it might revert back again after an update sometime in the future. BTW, you're "supposed" to edit the file /etc/texmf/texmf.d/95NonPath.cnf and then run update-texmf (as root) Excellent! Thanks Graham, that's exactly what I needed to know. I've bumped it now to 5 using the "correct" method, the value you and James have. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
I have created new [PATCH] issue for this: http://code.google.com/p/lilypond/issues/detail?id=1538 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened stems and flags (issue4134041)
I have created new [PATCH] issue for this: http://code.google.com/p/lilypond/issues/detail?id=1538 Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Beam collision push
Hey all, Han Wen - I saw that you pushed your beam collision work to master branch. I truly feel that this is premature and I urge you to undo it. The reason I have not pushed my patch yet is because I think more people need to chime in. This type of collision avoidance is very important to my current work as a composer, and the version that you pushed will not be able to correctly account for several types of collisions, as you saw in the files that I sent out to the list (unless you have modified it in a way of which I'm not aware), not least of which are the type that Neil sent out to the list and that my patch currently deals with. Collision avoidance is a brute-force manipulation of the beam that is difficulty to justify in quanting, which should deal with a discrete range of limited possibilities. It forces one into a cycle where one has to guess the appropriate region size to catch large collisions and recompile to see if one was right. In doing so, the region size increase invariably increases the time of compilation. It also does not allow for fine tuning of beam collisions on a grob-by-grob basis, which you see in action in the response I sent out to Neil. Please, again, I urge you to undo this before people start building on it. I do not believe that it is a tractable long-term solution, and I feel that pushing this early kills any dialogue on a better way of going about this. ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
`make test-baseline' failure in `remove-empty-staves-auto-knee.ly'
Hi Han-Wen, I'm using an unoptimized binary and get an assertion failure following the beam collision changes you've pushed: Processing `remove-empty-staves-auto-knee.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems...lilypond: ../flower/include/interval.hh:226: T Interval_t::center() const [with T = double]: Assertion `!is_empty ()' failed. It looks like you need to filter out cross-staff beams in init_collisions (). Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fine-tuning new flags - feedback needed
2011/2/24 Marek Klein > > I have created new [PATCH] issue for this: > http://code.google.com/p/lilypond/issues/detail?id=1538 Thanks for remembering! However, i'm afraid this issue is invalid. We decided to divide this problem and the first part is discussed in http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00391.html (i hope to upload a patch for that within a few hours). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: shortened stems and flags (issue4134041)
2011/2/24 Marek Klein > > I have created new [PATCH] issue for this: > http://code.google.com/p/lilypond/issues/detail?id=1538 Thanks for remembering! However, i'm afraid this issue is invalid. We decided to divide this problem and the first part is discussed in http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00391.html (i hope to upload a patch for that within a few hours). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
Hi Betrand, LGTM, apart from a few minor details. Cheers, Neil http://codereview.appspot.com/4182056/diff/15002/ly/toc-init.ly File ly/toc-init.ly (right): http://codereview.appspot.com/4182056/diff/15002/ly/toc-init.ly#newcode32 ly/toc-init.ly:32: tocItemWithDotsMarkup = \markup \fill-with-pattern #1 #RIGHT . this can be defined outside the \paper block http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3410 scm/define-markup-commands.scm:3410: Otherwise they are spread vertically. remove this line http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3421 scm/define-markup-commands.scm:3421: (let* ((pattern-width (interval-length (let (( http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3427 scm/define-markup-commands.scm:3427: (prepend-alist-chain 'word-space 0 (prepend-alist-chain 'baseline-skip 0 props)) move to separate binding above (e.g., `new-props') http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3428 scm/define-markup-commands.scm:3428: (if (zero? axis) (if (= axis X) http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3431 scm/define-markup-commands.scm:3431: (loop (1- i) indent (goes with (zero? i) above) http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3432 scm/define-markup-commands.scm:3432: (if (zero? axis) (if (= axis X) http://codereview.appspot.com/4182056/diff/15002/scm/define-markup-commands.scm#newcode3473 scm/define-markup-commands.scm:3473: #:pattern (1+ count) X space pattern I'm sorry I wasn't clearer about the indentation here: (markup left #:with-dimensions (cons 0 middle-width) '(0 . 0) #:translate (cons x-offset 0) #:pattern (1+ count) X space pattern http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: `make test-baseline' failure in `remove-empty-staves-auto-knee.ly'
On Thu, Feb 24, 2011 at 10:16 AM, Neil Puttock wrote: > Hi Han-Wen, > > I'm using an unoptimized binary and get an assertion failure following > the beam collision changes you've pushed: > > Processing `remove-empty-staves-auto-knee.ly' Thanks for the report. Duh. Pushing a patch... -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision push
On Thu, Feb 24, 2011 at 10:11 AM, Mike Solomon wrote: > Hey all, > > Han Wen - I saw that you pushed your beam collision work to master branch. > > I truly feel that this is premature and I urge you to undo it. The reason I > have not pushed my patch yet is because I think more people need to chime in. > This type of collision avoidance is very important to my current work as a > composer, and the version that you pushed will not be able to correctly > account for several types of collisions, as you saw in the files that I sent > out to the list (unless you have modified it in a way of which I'm not > aware), not least of which are the type that Neil sent out to the list and > that my patch currently deals with. > > Collision avoidance is a brute-force manipulation of the beam that is > difficulty to justify in quanting, which should deal with a discrete range of > limited possibilities. It forces one into a cycle where one has to guess the > appropriate region size to catch large collisions and recompile to see if one > was right. In doing so, the region size increase invariably increases the > time of compilation. It also does not allow for fine tuning of beam > collisions on a grob-by-grob basis, which you see in action in the response I > sent out to Neil. > > Please, again, I urge you to undo this before people start building on it. I > do not believe that it is a tractable long-term solution, and I feel that > pushing this early kills any dialogue on a better way of going about this. Let me cook something for the situations you need as well this weekend. Can you make a .ly with a few realistic samples of what you need? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
improving the transition between full-length and shortened stems. (issue4210051)
This patch handles transition between full length and shortened stems. It follows Han-Wen suggestions and supports custom stem length and custom staves. proof-sheets: Lily 2.13.47 output - http://www.sendspace.com/file/7fy9i4 this patch output - http://www.sendspace.com/file/tgmlfc source code: http://www.sendspace.com/file/3pusct http://codereview.appspot.com/4210051/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: transition between full-length and shortened stems - please discuss
Hi, 2011/2/22 Janek Warchoł > > I'll cook appropriate function tomorrow. > Thanks, > Janek I'm very sorry for the delay, i had some trouble with git. I've uploaded new patch for review, it supports custom stem lengths and staves with custom line count. See differences in output between original patch (variant 1): http://www.sendspace.com/file/d8jk3o and new patch: http://www.sendspace.com/file/tgmlfc Proof-sheet source code in attachment. I had to guess what the correct typography in this cases should look like, so i welcome any comments. http://codereview.appspot.com/4210051/ cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR accidental styles (issue4149045)
On 2011/02/24 06:32:25, Graham Percival wrote:
It's still not showy enough for me.
Well, maybe it's showy enough to resolve issue 1399. I posted the
output images of the examples to that tracker item.
http://code.google.com/p/lilypond/issues/detail?id=1399
Documentation/notation/pitches.itely:2527: Several accidental styles,
@code{modern} through @code{teaching}
Why are you telling me this?
Just as a segue into @ref{Accidentals}, where we have the snippet
showing how to set extraNatural.
Let's get the patch pushed with showing the accidentals without extra
naturals
and without any discussion of extraNatural.
New patch is up. Will wait a couple more days before pushing.
http://codereview.appspot.com/4149045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
Hi,
Thanks for your watchfulness ! (Can we say this? I'm pretty bad at
English...)
I added Graham and Neil's changes.
Regards,
Bertrand
(Git patch attached with the commit's informations)
From fe20aad02a7c4a6ace4a9c31670b5f4c7dbe87ba Mon Sep 17 00:00:00 2001
From: Bertrand Bordage
Date: Thu, 24 Feb 2011 23:50:18 +0100
Subject: [PATCH] New markup command : pattern
Issue 1517
* scm/define-markup-commands.scm
New markup commands : pattern
fill-with-pattern
* ly/toc-init.ly
Create tocItemWithDotsMarkup
* Documentation/changes.tely
* Documentation/notation/input.itely
How to use tocItemWithDotsMarkup
---
Documentation/changes.tely | 19 +
Documentation/notation/input.itely | 16 +++
ly/toc-init.ly |3 +
scm/define-markup-commands.scm | 77
4 files changed, 115 insertions(+), 0 deletions(-)
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index 002f6a8..d6700d9 100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -62,6 +62,25 @@ which scares away people.
@end ignore
@item
+Dots can be added to the table of contents items using:
+@example
+\paper @{
+ tocItemMarkup = \tocItemWithDotsMarkup
+@}
+@end example
+
+@item
+New markup commands @code{\pattern} and @code{\fill-with-pattern} are available.
+@lilypond
+\markup \column {
+ \pattern #3 #Y #0.3 \flat
+ \null
+ \pattern #7 #X #2 \flat
+ \override #'(line-width . 40) \fill-with-pattern #1 #CENTER . left right
+}
+@end lilypond
+
+@item
A minimal composer toolkit of modal transformations is provided.
A motif may be @notation{transposed}, @notation{inverted} and/or
converted to its @notation{retrograde} within any scale.
diff --git a/Documentation/notation/input.itely b/Documentation/notation/input.itely
index 50f6154..a7b36aa 100644
--- a/Documentation/notation/input.itely
+++ b/Documentation/notation/input.itely
@@ -957,6 +957,22 @@ tocAct =
}
@end lilypond
+Dots can be added to fill the line between an item and its page number:
+
+@lilypond[verbatim,quote]
+\header { tagline = ##f }
+\paper {
+ tocItemMarkup = \tocItemWithDotsMarkup
+}
+
+\book {
+ \markuplines \table-of-contents
+ \tocItem \markup { Allegro }
+ \tocItem \markup { Largo }
+ \markup \null
+}
+@end lilypond
+
@seealso
Init files: @file{../ly/toc-init.ly}.
diff --git a/ly/toc-init.ly b/ly/toc-init.ly
index dda4f31..488e22b 100644
--- a/ly/toc-init.ly
+++ b/ly/toc-init.ly
@@ -31,6 +31,9 @@
}
}
+tocItemWithDotsMarkup = \markup \fill-with-pattern #1 #RIGHT .
+ \fromproperty #'toc:text \fromproperty #'toc:page
+
#(define-markup-list-command (table-of-contents layout props) ()
( _i "Outputs the table of contents, using the paper variable
@code{tocTitleMarkup} for its title, then the list of lines
diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm
index 5dbc5d2..3e7c694 100644
--- a/scm/define-markup-commands.scm
+++ b/scm/define-markup-commands.scm
@@ -3397,6 +3397,83 @@ Negative values may be used to produce mirror images.
(ly:stencil-scale stil sx sy)))
+;; Repeating
+
+
+(define-markup-command (pattern layout props count axis space pattern)
+ (integer? integer? number? markup?)
+ #:category other
+ "
+Prints @var{count} times a @var{pattern} markup.
+Patterns are spaced apart by @var{space}.
+Patterns are distributed on @var{axis}.
+
+@lilypond[verbatim, quote]
+\\markup \\column {
+ \"Horizontally repeated :\"
+ \\pattern #7 #X #2 \\flat
+ \\null
+ \"Vertically repeated :\"
+ \\pattern #3 #Y #0.5 \\flat
+}
+@end lilypond"
+ (let ((pattern-width (interval-length
+ (ly:stencil-extent (interpret-markup layout props pattern) X)))
+(new-props (prepend-alist-chain 'word-space 0 (prepend-alist-chain 'baseline-skip 0 props
+(let loop ((i (1- count)) (patterns (markup)))
+ (if (zero? i)
+ (interpret-markup
+layout
+new-props
+(if (= axis X)
+(markup patterns pattern)
+(markup #:column (patterns pattern
+ (loop (1- i)
+(if (= axis X)
+(markup patterns pattern #:hspace space)
+(markup #:column (patterns pattern #:vspace space
+
+(define-markup-command (fill-with-pattern layout props space dir pattern left right)
+ (number? ly:dir? markup? markup? markup?)
+ #:category align
+ #:properties ((word-space)
+(line-width))
+ "
+Put @var{left} and @var{right} in a horizontal line of width @code{line-width}
+with a line of markups @var{pattern} in between.
+Patterns are spaced apart by @var{space}.
+Patterns are aligned to the @var{dir} markup.
+
+@lilypond[verbatim, quote]
+\\markup \\column {
+ \"right-aligned :\"
+ \\fill-with-patte
Re: Beam collision push
On Feb 24, 2011, at 11:23 AM, Mike Solomon wrote: > On Feb 24, 2011, at 10:52 AM, Han-Wen Nienhuys wrote: > >> On Thu, Feb 24, 2011 at 10:11 AM, Mike Solomon wrote: >>> Hey all, >>> >>> Han Wen - I saw that you pushed your beam collision work to master branch. >>> >>> I truly feel that this is premature and I urge you to undo it. The reason >>> I have not pushed my patch yet is because I think more people need to chime >>> in. This type of collision avoidance is very important to my current work >>> as a composer, and the version that you pushed will not be able to >>> correctly account for several types of collisions, as you saw in the files >>> that I sent out to the list (unless you have modified it in a way of which >>> I'm not aware), not least of which are the type that Neil sent out to the >>> list and that my patch currently deals with. >>> >>> Collision avoidance is a brute-force manipulation of the beam that is >>> difficulty to justify in quanting, which should deal with a discrete range >>> of limited possibilities. It forces one into a cycle where one has to >>> guess the appropriate region size to catch large collisions and recompile >>> to see if one was right. In doing so, the region size increase invariably >>> increases the time of compilation. It also does not allow for fine tuning >>> of beam collisions on a grob-by-grob basis, which you see in action in the >>> response I sent out to Neil. >>> >>> Please, again, I urge you to undo this before people start building on it. >>> I do not believe that it is a tractable long-term solution, and I feel that >>> pushing this early kills any dialogue on a better way of going about this. >> >> Let me cook something for the situations you need as well this >> weekend. Can you make a .ly with a few realistic samples of what you >> need? > An example from Bertrand Bordage. My patch produces the result where the beam is compressed to the middle of the staff. This is, according to him, standard practice in Breitkopf et Bärenreiter. I've also included a version produced with the current master, which pushes the beam below the A natural. My version cannot, however, do this right out of the box in all cases: it sometimes needs an override to catch the collision. Cheers, MS organ.ly Description: Binary data <><>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision push
Hi, You're cheating a bit, Mike ! This wasn't "c'4~ c'8." instead of "a4~ a8." in the lower voice. It's even more tight ! Here is the example in context (Breitkopf und Härtel 1878) : http://imslp.org/wiki/Special:ImagefromIndex/05677 The last two systems of the second page. You can also notice a similar case on the last PDF page. Last system, measure 2, third beat, upper staff. I also have many other cases of "three-voices-tight-situations" in more recent editions, especially Bärenreiter. I saw one day a XIXth century book with VERY tight music everywhere. Something like 6 voices Preludes and Fuges everywhere. Of course, beautifully engraved. If I could find it again... This thing is really the bible of beam collisions ! Now I have to go away for the WE. Regards, Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision push
Mistake in my second line : one must read "was" instead of "wasn't". Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision push
On Feb 24, 2011, at 10:21 PM, Bertrand Bordage wrote:Hi,You're cheating a bit, Mike !This wasn't "c'4~ c'8." instead of "a4~ a8." in the lower voice.It's even more tight ! Here is the example in context (Breitkopf und Härtel 1878) :http://imslp.org/wiki/Special:ImagefromIndex/05677The last two systems of the second page. You can also notice a similar case on the last PDF page. Last system, measure 2, third beat, upper staff.I also have many other cases of "three-voices-tight-situations" in more recent editions, especially Bärenreiter. I saw one day a XIXth century book with VERY tight music everywhere. Something like 6 voices Preludes and Fuges everywhere. Of course, beautifully engraved. If I could find it again... This thing is really the bible of beam collisions ! Now I have to go away for the WE.Regards,Bertrand Caught red-handed! I had changed it to an A when I was testing how far down the collision detection would go. But Bertrand's right: the original is even tighter (and attached in both the current master and my issue 37 work).___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal key signatures fix
Benkő Pál writes:
Graham Breed writes:
> If the accidentals aren't halves, the MIDI production fails.
Please explain in more detail, I never had such problems with MIDI.
The following (derived from an example in the manual) crashes:
\include "makam.ly"
mode = #`((6 . ,(- KOMA)) (3 . ,BAKIYE))
\score {
\relative c' {
\set Staff.keyAlterationOrder = #mode
\key c \mode
c4 cc db fk
gbm4 gfc gfb efk
fk4 db cc c
}
\layout{}
\midi{}
}
If we adapt this score to Felipé's integer representation, his patch avoids the crash but
outputs "6-sharps" as the key signature in MIDI. So regardless of the internal
representation of pitch, the computation producing the midi key signature needs Graham's
improvement.
The same problem comes up in European music with tunings like 19-ET, popular in
the 1600s, where C-sharp is 2/5 of a whole tone above C.
Graham Breed writes:
I've improved my patch. This line gives correct MIDI key signatures
for all plausibly authentic scenarios:
(apply + (map (lambda (p) (round (* (cdr p) 2))) pitch-list)) )
[...]
It would be nice to get a version number for
it being suppressed that I can submit a snippet against.
GrahamB,
There is already a report for this bug, at
http://code.google.com/p/lilypond/issues/detail?id=748
Actually, issue 748 reports two problems, so I combined your patch with a fix
for the other problem
soon link a patch to fix both. It will be linked to issue 748 as soon as the
self-test script finishes.
--
Keith
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Microtonal key signatures fix
On Thu, 24 Feb 2011 19:45:32 -0800, Keith OHara wrote: ... tunings like XX-ET, popular in the 1600s, where C-sharp is 2/5 of a whole tone above C. Argh. It is 31-ET that has the 2/5ths. People liked it because it nearly matched quarter-comma meantone. I should learn to look things up before I type instead of just after. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: improving the transition between full-length and shortened stems. (issue4210051)
On 2/24/11, lemniskata.bernoull...@gmail.com wrote: > This patch handles transition between full length and shortened stems. > It follows Han-Wen suggestions and supports custom stem length and > custom staves. Thanks, this now: http://code.google.com/p/lilypond/issues/detail?id=1538 Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR accidental styles (issue4149045)
LGTM http://codereview.appspot.com/4149045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add dots to tocItemMarkup (issue4182056)
LGTM. In light of the changes, let's have one more round of giving chances for reviews. http://codereview.appspot.com/4182056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix 748. Key signatures for modes (issue4237041)
LGTM, passes regtests. http://codereview.appspot.com/4237041/diff/2001/ly/arabic.ly File ly/arabic.ly (right): http://codereview.appspot.com/4237041/diff/2001/ly/arabic.ly#newcode36 ly/arabic.ly:36: (0 . ,NATURAL) This might cause a merge conflict in Felipe's work. I'm not criticizing it; this is a good change. I'm just point it out so that Felipe isn't surprised. http://codereview.appspot.com/4237041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour notice for toc dots, stem transitions, and doc accidentals
Sunday, 6am UK time. Add dots to tocItemMarkup http://code.google.com/p/lilypond/issues/detail?id=1517 improving the transition between full-length and shortened stems http://codereview.appspot.com/4210051/ Doc: NR accidental styles http://codereview.appspot.com/4149045/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: check your own
As a reminder, we're using the google tracker to organize patches: http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch&sort=patch 1) If you've submitted a patch recently (or even not recently), it should be in that list. If your patch isn't on that list, we've lost it. Sorry, please get in touch with us. 2) if your patch is on the "needs_work" list, then you should know what you need to fix. If you don't, then please get in touch with us. 3) if your patch is in the "abandoned" list and you're still working on it, please get in touch with us. 4) if your patch is in the "new" list, then I haven't checked it for obvious mistakes yet, but I'm strictly only doing 10 hours a week and nobody's yet volunteered to help me do this. Please continue to wait. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
