On 2011/05/11 23:12:08, Keith wrote:
http://codereview.appspot.com/4520050/diff/9001/flower/include/pqueue.hh#newcode110
flower/include/pqueue.hh:110: void del (vsize i)
Rather than change the 'flower' library to support deletion from the
heap, I
suggest we continue to use the ignore_ flag on
Reviewers: md5i,
Message:
This looks good overall.
I will test out my own suggestions, because if we can make a smaller
change, it will be easier to follow through this complicated stretch of
history in the MIDI-output code.
http://codereview.appspot.com/4520050/diff/1/flower/include/pqueue.hh
looks basically good.
http://codereview.appspot.com/4515042/diff/1/make/website.make
File make/website.make (right):
http://codereview.appspot.com/4515042/diff/1/make/website.make#newcode8
make/website.make:8: quiet-run = $(findstring s, $(MAKEFLAGS))
I think I'd still rather have this be:
quie
On May 11, 2011, at 2:19 PM, Neil Puttock wrote:
> On 11 May 2011 19:11, wrote:
>
>> The issue is that, for the chord bracket and chord slur (and Bertrand's
>> eventual chord brace, which hypothetically varies significantly in its X
>> dimension as it gets larger), the width of the grob is d
LGTM.
http://codereview.appspot.com/4489042/diff/1/input/regression/clef-octavation.ly
File input/regression/clef-octavation.ly (right):
http://codereview.appspot.com/4489042/diff/1/input/regression/clef-octavation.ly#newcode3
input/regression/clef-octavation.ly:3: \header{
\header {
http://co
On 11 May 2011 19:11, wrote:
> The issue is that, for the chord bracket and chord slur (and Bertrand's
> eventual chord brace, which hypothetically varies significantly in its X
> dimension as it gets larger), the width of the grob is dependent on knowing
> the extremal note head positions, w
On May 11, 2011, at 12:02 PM, n.putt...@gmail.com wrote:
>
> http://codereview.appspot.com/4517051/diff/1/lily/arpeggio.cc
> File lily/arpeggio.cc (right):
>
> http://codereview.appspot.com/4517051/diff/1/lily/arpeggio.cc#newcode98
> lily/arpeggio.cc:98: MAKE_SCHEME_CALLBACK (Arpeggio, internal_
LGTM
http://codereview.appspot.com/4518053/diff/5001/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):
http://codereview.appspot.com/4518053/diff/5001/Documentation/notation/staff.itely#newcode1090
Documentation/notation/staff.itely:1090: The @code{\transpositi
Reviewers: Graham Percival, Keith,
Message:
Second Draft
http://codereview.appspot.com/4518053/diff/1/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):
http://codereview.appspot.com/4518053/diff/1/Documentation/notation/staff.itely#newcode1022
Documentation/no
http://codereview.appspot.com/4517051/diff/1/lily/arpeggio.cc
File lily/arpeggio.cc (right):
http://codereview.appspot.com/4517051/diff/1/lily/arpeggio.cc#newcode98
lily/arpeggio.cc:98: MAKE_SCHEME_CALLBACK (Arpeggio, internal_print, 1);
Why are you exporting these internal functions?
http://co
On 11 May 2011 15:18, m...@apollinemike.com wrote:
> There is a note in arpeggio.cc saying that width cannot be gleaned from the
> print function because it triggers a vertical alignment when arpeggios are
> cross-staff. By turning the function into an internal function and calling
> it form
On May 11, 2011, at 9:51 AM, carl.d.soren...@gmail.com wrote:
> Seems reasonable to me.
>
> I couldn't think of any way to generalize the internal call.
>
> Carl
>
>
> http://codereview.appspot.com/4517051/
Thanks!
There is a note in arpeggio.cc saying that width cannot be gleaned from the
Seems reasonable to me.
I couldn't think of any way to generalize the internal call.
Carl
http://codereview.appspot.com/4517051/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Small variable nit upon rereading this patch. No change in semantics.
http://codereview.appspot.com/4520050/diff/1/flower/include/pqueue.hh
File flower/include/pqueue.hh (right):
http://codereview.appspot.com/4520050/diff/1/flower/include/pqueue.hh#newcode121
flower/include/pqueue.hh:121: vsiz
LGTM.
I like the results!
http://codereview.appspot.com/4518052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
:)
Thanks ! This works great. Updated.
http://codereview.appspot.com/4518052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/05/11 09:54:36, dak wrote:
Something like
fatten := min(number/256,1)[1+fatten_factor,1];
should do the trick then.
Well, I repeat the suggestion to make fatten_factor neutral at 1 instead
of 0 (resulting in omitting 1+ in the above formula), and perhaps
instead of hardcoding 256, one c
On 2011/05/11 09:22:14, Bertrand Bordage wrote:
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode151
mf/feta-braces.mf:151: fatten := 1 + fatten_factor - min ( number *
fa
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode151
mf/feta-braces.mf:151: fatten := 1 + fatten_factor - min ( number *
fatten_factor / 256, fatten_factor);
Thanks !
Hum...
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf
File mf/feta-braces.mf (right):
http://codereview.appspot.com/4518052/diff/2002/mf/feta-braces.mf#newcode151
mf/feta-braces.mf:151: fatten := 1 + fatten_factor - min ( number *
fatten_factor / 256, fatten_factor);
This is a bit ob
I don't know if this is a joke, so I answer to David's question :
of course there is no jump between the 256th and the 257th !
Refer to this message to see before/after :
http://lists.gnu.org/archive/html/lilypond-devel/2011-05/msg00150.html
http://codereview.appspot.com/4518052/
___
2011/5/11 Francisco Vila :
> 2011/5/11 :
>> If you say you fatten the first 256 braces, does that mean that there is
>> a jump in thickness when going from the 256th to the 257th brace?
>
> Is it a joke?
Oh, of course it is. Sorry :*)
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.cs
2011/5/11 :
> If you say you fatten the first 256 braces, does that mean that there is
> a jump in thickness when going from the 256th to the 257th brace?
Is it a joke?
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
___
lilyp
If you say you fatten the first 256 braces, does that mean that there is
a jump in thickness when going from the 256th to the 257th brace?
In that case, would it not be better to have a smoother transition
rather than a jump? Metafont is good at curves, after all...
http://codereview.appspot.co
24 matches
Mail list logo
