Am 31.10.2010 00:07, schrieb Neil Puttock:
On 30 October 2010 22:40, Marc Hohlm...@hohlart.de wrote:
File /home/marc/git/lilypond/python/out/book_snippets.py, line 561, in
compose_ly
if self.global_options.safe_mode:
AttributeError: Values instance has no attribute 'safe_mode'
Hello Carl,
wow, you were fast ...
LGTM ;-)
As said before, I wouldn't be able to do this engraver myself, but I
think I understand now a tiny bit better how
c++ engraver work.
Thank you,
Marc
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc
File
I may be missing something, but doesn't this assume all line spanners
are glissandi?
Trevor
http://codereview.appspot.com/2723043/diff/1/lily/tab-tie-follow-engraver.cc
File lily/tab-tie-follow-engraver.cc (right):
On 2010/10/31 09:29:29, Trevor Daniels wrote:
I may be missing something, but doesn't this assume all line spanners
are
glissandi?
I thought the same thing. I haven't investigated it carefully; I was
just translating Marc's Scheme engraver to C++.
Any comments, Mark?
Thanks,
Carl
I've updated the comments and the doc string,
and added a check for Glissando.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sun, Oct 31, 2010 at 4:33 AM, carl.d.soren...@gmail.com wrote:
I've put a new patch up on Rietveld, with the Scheme engraver moved to a
C++ engraver to avoid the challenges with documentation.
Thanks Carl! In the meantime, I've opened
http://code.google.com/p/lilypond/issues/detail?id=1375
Reviewers: ,
Message:
Docs look ok, but I'm not 100% certain about the changes to chords, or
whether Trevor wants us changing vocal.itely.
(this is a git-cl-merge of James Lowe's initial doc patch, and a few
fixes I applied to that one; I don't think it's worth separating this
into two separate
Le 31/10/2010 02:42, Francisco Vila disait :
2010/10/30 Graham Percivalgra...@percival-music.ca:
On Sat, Oct 30, 2010 at 01:51:14AM +0200, Francisco Vila wrote:
2010/10/30 Francisco Vilapaconet@gmail.com:
this is to ask if anyone, besides me, has noticed that rextend macro
sometimes
I've only reviewed the chords section, since Graham was unsure about it.
I think that it most cases, there should be no \relative in these
sections.
Thanks,
Carl
http://codereview.appspot.com/2810041/diff/1/Documentation/notation/chords.itely
File Documentation/notation/chords.itely (right):
On 2010/10/31 13:54:01, Carl wrote:
I think the relative should only be included with figures:
1. When there are notes, and
2. When we want the notes in relative mode.
Ok, I've removed all [relative=?] unless there's a combination of notes
with \chordmode or \figures. Will upload once
Since the spacing alist bug seemed to be a problem for people
experimenting with the spacing stuff, I went ahead with 2.13.38 to get
that bugfix out there.
Bug squad: Phil is busy with the opening of a musical, so it would be
nice if somebody else could check the regression test comparisons for
Clef support for cue notes
-) Added \cleffedCueDuring, which allows to specify a clef for
the cue notes. At the end of the cue section, the clef is
automatically reset to the containing voice's clef.
-) Cue clefs are implemented as CueClef and CueEndClef grobs,
created by a dedicated
Han-Wen Nienhuys hanw...@gmail.com writes:
On Fri, Oct 29, 2010 at 8:46 AM, David Kastrup d...@gnu.org wrote:
Are there good reasons left for not allowing music functions to take
pitches as arguments? That would allow implementing something like
how would you encode the pitch though? Does
Valentin Villenave valen...@villenave.net writes:
On Sun, Oct 31, 2010 at 5:29 PM, David Kastrup d...@gnu.org wrote:
Perhaps I have not put myself forward reasonably clearly: the idea was
not just to use a predicate in the function signature, but to let that
predicate be special-cased in the
Hi Reinhold,
it certainly looks good! I haven't tested your patch set though, so
these are just a couple of nitpicks off the top of my head.
http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly
File input/regression/cue-clef.ly (right):
On Sun, Oct 31, 2010 at 07:32:50PM +, v.villen...@gmail.com wrote:
http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly#newcode4
input/regression/cue-clef.ly:4: texidoc = Clefs for cue notes: Normal
clefs should be printed, and in addition
Is it Normal that this word
http://codereview.appspot.com/2726043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Oops, somehow I've just created an empty comment.
http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
http://codereview.appspot.com/2726043/diff/1/ly/music-functions-init.ly#newcode238
ly/music-functions-init.ly:238: cleffedCueDuring
On Fri, 29 Oct 2010 21:04:06 -0700, lilypond-devel-requ...@gnu.org wrote:
Mark Polesky wrote Friday, October 29, 2010 11:27 PM
I've thought about it, and I think I slightly favor the term
loose line over non-staff line
[...]
Also loose-staff-spacing sounds
too much like something that
Reviewers: ,
Message:
This patch...
1) adds a node to NR 5.3 Modifying properties that
explains alist-modifying in a generic way, and
2) removes the similar material from
NR 4.1.2 Page formatting.
However, there are two statements I want to make, but I'm
not certain if they are entirely
On Sun, Oct 31, 2010 at 8:43 PM, Graham Percival
gra...@percival-music.ca wrote:
In correct English, that word would be capitalized. However, most
people don't bother to write that well. So it's not normal to see
this capitalized correctly. :)
Interesting. Could you elaborate?
On Sun, Oct
Hi Carl,
This is too complicated (though that's really a criticism of Marc's
Scheme engraver).
The point of using 'tie-follow is that it defers the decision to
parenthesize TabNoteHead to the point where it matters: in the callbacks
for Glissando and Slur. Thus there should be no need to
-Original Message-
From: lilypond-devel-bounces+james.lowe=datacore@gnu.org on behalf of
Valentin Villenave
Sent: Sun 31/10/2010 22:12
To: Graham Percival
Cc: re...@codereview.appspotmail.com; lilypond-devel@gnu.org
Subject: Re: Clef support for cue notes (issue2726043)
On Sun, Oct
On 2010/10/31 22:24:17, Neil Puttock wrote:
Hi Carl,
This is too complicated (though that's really a criticism of Marc's
Scheme
engraver).
The point of using 'tie-follow is that it defers the decision to
parenthesize
TabNoteHead to the point where it matters: in the callbacks for
On 2010/10/31 22:24:17, Neil Puttock wrote:
http://codereview.appspot.com/2723043/diff/7001/lily/tab-tie-follow-engraver.cc#newcode69
lily/tab-tie-follow-engraver.cc:69: if (info.grob ()-name () ==
Glissando)
If you needed to distinguish glissandos from other lines, it would be
more
On Sun, Oct 31, 2010 at 11:26 PM, James Lowe james.l...@datacore.com wrote:
If it's being used as a 'proper noun' it would be capitalised.
I fail to see how it is a proper noun. Clefs that are normal -
adjective, isn't it?
But it seems the rules are slightly different for American English
On 2010/10/31 22:40:57, Carl wrote:
This is going away, so it won't apply to this patch (because we don't
need to
acknowledge glissandos). But if we did, and we added a
glissando-interface,
then instead of Tab_tie_follow_engraver::acknowledge_line_spanner
wouldn't we
just use
New patch set with simplified engraver -- it only acknowledges ties and
note-heads, and it still works.
Thanks, Neil!
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
On 2010/10/31 21:54:41, Mark Polesky wrote:
This patch...
1) adds a node to NR 5.3 Modifying properties that
explains alist-modifying in a generic way, and
2) removes the similar material from
NR 4.1.2 Page formatting.
However, there are two statements I want to make, but I'm
On 10/31/10 3:00 PM, Keith E OHara k-ohara5...@oco.net wrote:
On Fri, 29 Oct 2010 21:04:06 -0700, lilypond-devel-requ...@gnu.org wrote:
Mark Polesky wrote Friday, October 29, 2010 11:27 PM
I've thought about it, and I think I slightly favor the term
loose line over non-staff line
Further thought about this causes me to think the engraver should just
be
Tie_follow_engraver
It doesn't change a TabNoteHead property, it changes a NoteHead
property. The only reason it applies to TabNoteHeads is because it is
in a TabVoice context.
Am I wrong in thinking this?
Thanks,
Or perhaps the engraver should only listen to tab-note-heads, instead of
to note-heads, since the tie-follow property is part of the
tab-note-head interface.
Thanks,
Carl
http://codereview.appspot.com/2723043/
___
lilypond-devel mailing list
32 matches
Mail list logo
