Hi Keith,
Did you intend to remove the dodecaphonic accidentals snippet from our
docs? If so (i.e. it's been replaced with 2.13 functionality), then
we needs some magic in Documentation/snippets/new/ . See
changing-the-time-signature-without-affecting-the-beaming.ly
for an example.
Cheers,
-
Reviewers: hanwenn, ahawryluk,
Message:
New patch uploaded, but I'm not totally certain it's correct. The
message in Documentation/snippets/* is misleading -- you shouldn't edit
them directly (instead, edit stuff in /new/ ), but of course those files
are modified when you run makelsr.py, and tho
On 2/27/11, Janek Warchoł wrote:
> Here you are. This contains all the changes and should apply cleanly
> to origin/master.
Thanks, pushed.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/l
On 2011/02/28 04:06:03, hanwenn wrote:
There are two issues in the regtest: it gets confused by x-staff
beams, and it
tries to avoid the start of staff clef when the beam crosses a line
breaks.
fixed.
http://codereview.appspot.com/4239047/
___
lil
My bad!
The attached post corrects this oversight. Graham, can you upload
this? I won't get a chance to figure out that git-cl this week.
Andrew
On Sun, Feb 27, 2011 at 5:16 PM, wrote:
>
> http://codereview.appspot.com/4243041/diff/1/Documentation/snippets/editorial-headword.ly
> File Documenta
On Mon, Feb 28, 2011 at 1:06 AM, wrote:
> this fixes the most egregious errors of the brute force quanting.
>
> There are two issues in the regtest: it gets confused by x-staff beams,
> and it tries to avoid the start of staff clef when the beam crosses a
> line breaks.
>
> I'll fix those problem
Reviewers: MikeSol,
Message:
this fixes the most egregious errors of the brute force quanting.
There are two issues in the regtest: it gets confused by x-staff beams,
and it tries to avoid the start of staff clef when the beam crosses a
line breaks.
I'll fix those problems, but don't expect lar
On Feb 27, 2011, at 8:07 PM, Han-Wen Nienhuys wrote:
> On Sun, Feb 27, 2011 at 1:25 PM, Mike Solomon wrote:
>> Should be fixed...
>
> Can you dedicate a commit to documenting/commenting how the engraver
> deals with beams? I couldn't work out reading how the engraver deals
> with (auto)beams, a
On Sun, Feb 27, 2011 at 1:25 PM, Mike Solomon wrote:
> Should be fixed...
Can you dedicate a commit to documenting/commenting how the engraver
deals with beams? I couldn't work out reading how the engraver deals
with (auto)beams, and more importantly, I couldn't understand why
your fix solves a
Thanks Neil!
Just a couple questions below - everything else was pretty automatic.
http://codereview.appspot.com/4213042/diff/34032/input/regression/footnotes.ly
File input/regression/footnotes.ly (right):
http://codereview.appspot.com/4213042/diff/34032/input/regression/footnotes.ly#newcode7
http://codereview.appspot.com/4243041/diff/1/Documentation/snippets/editorial-headword.ly
File Documentation/snippets/editorial-headword.ly (right):
http://codereview.appspot.com/4243041/diff/1/Documentation/snippets/editorial-headword.ly#newcode2
Documentation/snippets/editorial-headword.ly:2:
http://codereview.appspot.com/4236047/diff/1/lily/include/prob.hh
File lily/include/prob.hh (right):
http://codereview.appspot.com/4236047/diff/1/lily/include/prob.hh#newcode59
lily/include/prob.hh:59: void set_boolean_property (const char *sym,
bool val);
can you use set_property() rather than
2011/2/27 :
> On 2011/02/27 07:39:02, wl_gnu.org wrote:
>>
>> > Well, this nuber is not formed :) It shouldn't depend on
>> > staff_radius. This number determines what the steepness of
>> > transition should be (i.e., what the angle of the red line in the
>> > attachment will be). This angle shou
Omitted to cc -devel ...
- Original Message -
From: "Trevor Daniels"
To:
Sent: Sunday, February 27, 2011 7:53 PM
Subject: Re: Regression test failure in 2.13.52
Mike
Looks good now. The problem I reported looks to be
fixed, and some misplaced beams apparent in 2.13.51
are fixed t
http://codereview.appspot.com/4213042/diff/34032/input/regression/footnotes.ly
File input/regression/footnotes.ly (right):
http://codereview.appspot.com/4213042/diff/34032/input/regression/footnotes.ly#newcode7
input/regression/footnotes.ly:7: \book { }
Sorry, I meant wrap all the music inside a
On Feb 27, 2011, at 4:24 PM, n.putt...@gmail.com wrote:
> On 2011/02/27 04:11:56, MikeSol wrote:
>
>
> http://codereview.appspot.com/4213042/diff/40001/lily/footnote-engraver.cc
>> File lily/footnote-engraver.cc (right):
>
>
> http://codereview.appspot.com/4213042/diff/40001/lily/footnote-engr
On 2011/02/27 04:11:56, MikeSol wrote:
http://codereview.appspot.com/4213042/diff/40001/lily/footnote-engraver.cc
File lily/footnote-engraver.cc (right):
http://codereview.appspot.com/4213042/diff/40001/lily/footnote-engraver.cc#newcode60
lily/footnote-engraver.cc:60: Grob * b = make_item (
Am Sonntag, 27. Februar 2011, um 21:03:35 schrieb Graham Percival:
> On Sun, Feb 27, 2011 at 11:20:18AM -0800, Patrick McCarty wrote:
> > It is worth noting that `git rebase' is a very powerful command, since
> > you can potentially rewrite all of git history with it. So, in
> > general, be carefu
On Sun, Feb 27, 2011 at 11:20:18AM -0800, Patrick McCarty wrote:
> On Sun, Feb 27, 2011 at 7:00 AM, Graham Percival
> wrote:
> > git rebase -i master^^
> > (however many ^ you need to cover all your recent work)
> > This lets you clean up your git history before pushing to master,
> > thereby
Am Sonntag, 27. Februar 2011, um 20:20:18 schrieb Patrick McCarty:
> It is worth noting that `git rebase' is a very powerful command, since
> you can potentially rewrite all of git history with it. So, in
> general, be careful that you're not modifying commits that have
> already been pushed to sa
On Sun, Feb 27, 2011 at 7:00 AM, Graham Percival
wrote:
> Hi Mike,
>
> Could I introduce you to the wonders of git-rebase ? In
> particular:
> git rebase -i master^^
> (however many ^ you need to cover all your recent work)
> This lets you clean up your git history before pushing to master,
Hi Boris,
Just a code nitpick (in two places).
Please remember to Cc: lilypond-devel for Rietveld patches so that we
know code review is taking place.
Thanks,
Patrick
http://codereview.appspot.com/4236047/diff/1/lily/paper-book.cc
File lily/paper-book.cc (right):
http://codereview.appspot.co
Several regression tests fail in 2.13.52. Beams
are misplaced, some randomly in different runs,
and some fail with "no beam positions?" error.
Here's the output of one:
GNU LilyPond 2.13.52
Processing `collision-merge-differently-dotted.ly'
Parsing...
Interpreting music...
Preprocessing graphi
I'm really sorry about that - I've pushed a fix. Han Wen is trying to fix his
beam collision stuff in the quanting, and I had pushed part of my old engraver
which I thought would help fix some issues but actually breaks his code. That
is now cleaned up - everything should work.
Cheers,
MS
On
On Sun, Feb 27, 2011 at 04:04:00PM +0100, Nicolas Sceaux wrote:
> Le 27 févr. 2011 à 15:17, carl.d.soren...@gmail.com a écrit :
>
> > P.S. Can you propose your patch to git-cl to the git-cl maintainers? I
> > think that your approach is the right one. But I don't want to have us
> > in the posi
Le 27 févr. 2011 à 15:17, carl.d.soren...@gmail.com a écrit :
> P.S. Can you propose your patch to git-cl to the git-cl maintainers? I
> think that your approach is the right one. But I don't want to have us
> in the position of needing a custom git-cl.
I thought git-cl was shipped in whatever
Hi Mike,
Could I introduce you to the wonders of git-rebase ? In
particular:
git rebase -i master^^
(however many ^ you need to cover all your recent work)
This lets you clean up your git history before pushing to master,
thereby giving us a much less cluttered history.
I also recommend r
LGTM.
Thanks,
Carl
P.S. Can you propose your patch to git-cl to the git-cl maintainers? I
think that your approach is the right one. But I don't want to have us
in the position of needing a custom git-cl.
http://codereview.appspot.com/4176056/
___
On 2011/02/17 18:39:21, Carl wrote:
On 2011/02/17 16:17:29, nicolas.sceaux wrote:
> There is also a modification of the first fret label position, but
maybe this
is
> a mistake. Is the label supposed to be vertically centered with the
fret line?
> or the bottom of the label should be align
Hi Han-Wen,
Thank you for pointing out this defect.
I have created patch 4236027 to address it:
http://codereview.appspot.com/4236047
To answer your question, what the "if" was supposed to be doing: the
idea was to guard against the situation where there the whole paragraph
consists of only on
On Sun, Feb 27, 2011 at 12:20:47PM -, Trevor Daniels wrote:
>
> Trevor Daniels wrote Sunday, February 27, 2011 12:17 PM
>
> >Graham Percival wrote Sunday, February 27, 2011 8:45 AM
> >
> >>Tues, 9am UK time.
> >
> >? I know you keep strange hours, but this is a little
> >too strange ;)
A 25
On 2011/02/27 07:39:02, wl_gnu.org wrote:
> Well, this nuber is not formed :) It shouldn't depend on
> staff_radius. This number determines what the steepness of
> transition should be (i.e., what the angle of the red line in the
> attachment will be). This angle shouldn't depend on Staff_radius
Tues, 9am UK time.
Fix 748. Key signatures for modes
http://codereview.appspot.com/4237041/
Change keep-inside-line defaults to true
http://codereview.appspot.com/4243041/
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http:
33 matches
Mail list logo
