Eric Knapp wrote Thursday, January 21, 2010 2:36 AM
My goal is to determine the fingering
number and the string number
Is there a way to determine the digit
and string-number directly by name? It looks like the
articulations
are a list. Would it be possible to loop through the list and
det
On Wed, Jan 20, 2010 at 10:44 PM, Mark Polesky wrote:
> Patrick McCarty wrote:
>>> * New compiling requirements:
>>> - GCC 4.0
>> Are you sure this is required?
>> OpenBSD's gcc 3.3.5 apparently works okay with this patch:
>> http://lists.gnu.org/archive/html/lilypond-devel/2009-12/msg00324.html
Marc Hohl wrote:
Alexander Kobel schrieb:
Marc Hohl wrote:
Trevor Daniels schrieb:
It is easy
for a user to move the sign to the end of the staff lines with
\once \override Score.BarLine #'extra-offset = #'(1 . 0)
\once \override Score.SpanBar #'extra-offset = #'(1 . 0)
[...]
Would it m
Quoting Joe Neeman :
Again, I'd suggest uploading patches to codereview.appspot.com, which
provides nice formatting and makes it easy to have multiple reviewers.
Ok, I've created Issue 190102 for this.
One inconvenience that I see with the "upload.py" tool, is that I don't
see a way to spe
Hi all!
Attending to a seminar about French typography, I've printed several
pages of "notation.fr.pdf", and noticed something disturbing. I checked
the English version, guessing it might be a problem with translations
only, but it is not.
Here is an example of page 189 of the notation manu
lgtm, modulo some more formatting nitpicking. If you fix the formatting
and mail me the patch, I'll push it.
Also, in the future, please add lilypond-devel@gnu.org to the CC list (I
should have mentioned it, sorry).
http://codereview.appspot.com/190102/diff/1/2
File lily/constrained-breaking.c
On Thu, 2010-01-21 at 13:51 -0500, Boris Shingarov wrote:
> Quoting Joe Neeman :
>
> > Again, I'd suggest uploading patches to codereview.appspot.com, which
> > provides nice formatting and makes it easy to have multiple reviewers.
>
> Ok, I've created Issue 190102 for this.
>
> One inconvenie
On Thu, Jan 21, 2010 at 09:24:32PM +0100, Jean-Charles Malahieude wrote:
> Attending to a seminar about French typography, I've printed several
> pages of "notation.fr.pdf", and noticed something disturbing.
> -8<
> See also
>Notation Reference: Section A.8.1 [Font], page
lgtm, modulo some more formatting nitpicking. If you fix the formatting
and mail me the patch, I'll push it.
Here it is.
--
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/0419
diff --git a/lily/constrained-b
On Sun, 2010-01-17 at 04:50 -0800, -Eluze wrote:
> i thinke there is a remainder from earlier versions in the notation
> reference:
>
> 4.6.2 Changing spacing
>
> between-system-space = #0.1
>
> should be replaced by
>
> between-system-spacing = #0.1
Thanks, fixed. Although it should be
betw
http://codereview.appspot.com/190102/diff/1/2
File lily/constrained-breaking.cc (right):
http://codereview.appspot.com/190102/diff/1/2#newcode529
lily/constrained-breaking.cc:529: last_markup_line_ =
to_boolean(last_scm);
On 2010/01/21 20:45:06, joeneeman wrote:
space before (
Done.
http://
Thanks, pushed.
On Thu, 2010-01-21 at 23:02 +, shinga...@gmail.com wrote:
> http://codereview.appspot.com/190102/diff/1/2
> File lily/constrained-breaking.cc (right):
>
> http://codereview.appspot.com/190102/diff/1/2#newcode529
> lily/constrained-breaking.cc:529: last_markup_line_ =
> to_boo
Does anybody object to this patch? Alternately, is anybody
willing to rewrite the GNUmakefile portion to make it like a real
makefile?
Cheers,
- Graham
>From 5cee5fd0b10f4a6ed8f86de4591cda23bea1ec27 Mon Sep 17 00:00:00 2001
From: Graham Percival
Date: Fri, 22 Jan 2010 00:18:18 +
Subject: [
On 2010-01-11, Alexander Kobel wrote:
>
> The attached patch for fill-line (scm/define-markup-commands.scm)
> should do the expected thing.
> fill-line currently only considers the extents of the stencils, not
> their position relative to the X-origin; with the patch, they are
> shifted according
In response to a request from Patrick Schmidt on the tablatures list, I
became aware of the fact that we have two separate methods of finding
strings and frets given notes -- one for the tab-note-heads-engraver and one
for the fretboards-engraver.
This didn't seem to me to be a very good situation
Le vendredi 22 janvier 2010 à 00:35 +, Graham Percival a écrit :
> Does anybody object to this patch? Alternately, is anybody
> willing to rewrite the GNUmakefile portion to make it like a real
> makefile?
I don't care too much for the makefile, but please fix the shebang of
the Python script
16 matches
Mail list logo