On 2020/02/28 09:32:57, hahnjo wrote:
> On 2020/02/28 09:23:44, benko.pal wrote:
> > it may not matter, but actually long is 32 bit, void * is 64 bit on
current
> > native 64 bit platforms too, I believe.
>
> Only mingw, on Linux long is 64 bit AFAICT. See also
> https://stackoverflow.com/a/384672
it may not matter, but actually long is 32 bit, void * is 64 bit on
current native 64 bit platforms too, I believe.
https://codereview.appspot.com/579340043/
On 2020/02/06 14:29:55, Dan Eble wrote:
> The reviewers are turning the first question I asked around and asking
it back
> to me. I don't know if this is useful without other stuff I've been
working on.
> That's why I've posted it for review. I thought that you (well,
mainly I
> thought that Dav
On 2020/01/29 06:43:19, hanwenn wrote:
> score performer
removed unused: looks good.
changing references to pointers: looks BD.
https://codereview.appspot.com/577440044/
https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc
File lily/parse-scm.cc (right):
https://codereview.appspot.com/577410045/diff/581560047/lily/parse-scm.cc#newcode77
lily/parse-scm.cc:77: const Input *hi = &ps->start_;
I understand (and like) adding the const, but can't u
On 2020/01/22 10:15:03, hanwenn wrote:
> Why do we need to have the distinction between size_t and int? I know
the
> standard library returns size_t in some places, but is there any
reason for
> LilyPond to used unsigned integers anywhere?
It's not just the sign (btw I like unsigned integers):
th
LGTM
https://codereview.appspot.com/58343/diff/568950043/Documentation/snippets/figured-bass-headword.ly
File Documentation/snippets/figured-bass-headword.ly (right):
https://codereview.appspot.com/58343/diff/568950043/Documentation/snippets/figured-bass-headword.ly#newcode35
Documentat
LGTM
https://codereview.appspot.com/576610043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2018/07/10 18:09:19, dak wrote:
On 2018/07/10 17:49:33, dak wrote:
> On 2018/07/10 17:10:53, benko.pal wrote:
> > LGTM; just by looking I can't see how it can make make fail.
> > using rp[-2] and rp[-1] instead of lastcol and c would be cleaner
to me, but
> > YMMV.
>
> Since the whole point
LGTM; just by looking I can't see how it can make make fail.
using rp[-2] and rp[-1] instead of lastcol and c would be cleaner to me,
but YMMV.
https://codereview.appspot.com/351720043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lis
On 2018/01/03 20:37:33, Malte Meyn wrote:
I think you’re right. (I found the German translation at our
university
library.)
For single measure rests she writes (section II.6)
• semibrevis rest for any time signature
• exception: brevis rest for 4/2, 8/4 and longer
→ LilyPond does this but ad
if it's really the same, can't it be used without copying? or if
separate classes are absolutely needed, can't the common part be
gathered in a common base class?
https://codereview.appspot.com/335910043/
___
lilypond-devel mailing list
lilypond-devel
https://codereview.appspot.com/330120043/diff/1/scm/parser-clef.scm
File scm/parser-clef.scm (right):
https://codereview.appspot.com/330120043/diff/1/scm/parser-clef.scm#newcode96
scm/parser-clef.scm:96: ("petrucci-g2" . ("clefs.petrucci.g" -2 0))
On 2017/09/10 13:02:25, pkx166h wrote:
Is this
Reviewers: ,
Message:
g1 clef occurs in English manuscripts;
f2 clef occurs in Ockeghem's Missa prolationum (Chigi codex)
Description:
add some rarely used mensural clefs
and an alias petrucci-g2 to petrucci-g
Please review this at https://codereview.appspot.com/330120043/
Affected files (+9,
LGTM
https://codereview.appspot.com/299510043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/292370043/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
https://codereview.appspot.com/292370043/diff/1/Documentation/contributor/source-code.itexi#newcode2296
Documentation/contributor/source-code.itex
LGTM
https://codereview.appspot.com/288100043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Is this needed in some environments/with some git versions? git cl with
a space always worked for me (just as all the regular git commands did).
It doesn't hurt though, so LGTM.
https://codereview.appspot.com/282960043/
___
lilypond-devel mailing list
sorry to chime in that late, but:
am I right that the problem is that we get the rotation matrix
cos a -sin a
sin acos a
inexact? and if so, how the inexactness is present? one of the
diagonals is exactly +/-1 while the other is not exactly 0?
in that case I'd suggest (would have suggested
https://codereview.appspot.com/264950043/diff/40001/lily/include/grob-array.hh
File lily/include/grob-array.hh (right):
https://codereview.appspot.com/264950043/diff/40001/lily/include/grob-array.hh#newcode63
lily/include/grob-array.hh:63: // Note: This method may reorder the
array without affec
https://codereview.appspot.com/256340043/diff/1/input/regression/ssaattbb-template-with-changed-instrument-names.ly
File input/regression/ssaattbb-template-with-changed-instrument-names.ly
(left):
https://codereview.appspot.com/256340043/diff/1/input/regression/ssaattbb-template-with-changed-ins
that's fabulous, thanks!
https://codereview.appspot.com/251130043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/252810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/235790043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
looks exciting to me; my only comment is about a comment
https://codereview.appspot.com/235790043/diff/1/lily/include/listener.hh
File lily/include/listener.hh (right):
https://codereview.appspot.com/235790043/diff/1/lily/include/listener.hh#newcode27
lily/include/listener.hh:27: register a met
On 2015/01/02 08:56:03, dak wrote:
On 2015/01/02 07:21:19, benko.pal wrote:
> On 2015/01/01 23:08:56, Dan Eble wrote:
> > On 2015/01/01 22:57:31, benko.pal wrote:
> > >
https://codereview.appspot.com/189420043/diff/1/lily/breathing-sign.cc
> > > File lily/breathing-sign.cc (right):
> > >
> > >
On 2015/01/01 23:08:56, Dan Eble wrote:
On 2015/01/01 22:57:31, benko.pal wrote:
>
https://codereview.appspot.com/189420043/diff/1/lily/breathing-sign.cc
> File lily/breathing-sign.cc (right):
>
>
https://codereview.appspot.com/189420043/diff/1/lily/breathing-sign.cc#newcode122
> lily/breath
https://codereview.appspot.com/189420043/diff/1/lily/breathing-sign.cc
File lily/breathing-sign.cc (right):
https://codereview.appspot.com/189420043/diff/1/lily/breathing-sign.cc#newcode122
lily/breathing-sign.cc:122: if (ydim[DOWN] < val && line_pos.begin () <
it - 1)
I'd rather write
line_pos.
On 2014/10/26 17:24:01, Dan Eble wrote:
On 2014/10/26 07:40:58, benko.pal wrote:
> I think we don't want 4/8 displayed as C by default
Then this change should not bother you because this new style is not
the
default.
ah, indeed, sorry for the noise.
https://codereview.appspot.com/16483004
I think we don't want 4/8 displayed as C by default, neither 2/4 as cut
C.
(I also feel uncomfortable to enter \time 2/1 for the Bach Kyrie or
Gratias.)
https://codereview.appspot.com/164830043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
ht
https://codereview.appspot.com/10946/diff/150001/scripts/auxiliar/make-countdown-announcement.sh
File scripts/auxiliar/make-countdown-announcement.sh (right):
https://codereview.appspot.com/10946/diff/150001/scripts/auxiliar/make-countdown-announcement.sh#newcode22
scripts/auxiliar/make-
LGTM
https://codereview.appspot.com/50400044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
>>> However, if you don't mind, i'd prefer to leave it as is - i have
>>> _already_ spent about 4 hours cleaning up and rebasing commits to
make
>>> them somewhat ordered for review, and i'm quite tired.
>>
>>
>> I do mind. this is not the sort of thing that can be done in a
>> follow up patch.
Reviewers: ,
Message:
continuation of
http://codereview.appspot.com/38530043
belonging to
http://code.google.com/p/lilypond/issues/detail?id=3705
if requested, I can either update dev/janek/metafont-cleanup or push as
a new branch.
Description:
splitting file movement and whitespace-only change
However, if you don't mind, i'd prefer to leave it as is - i have
_already_ spent about 4 hours cleaning up and rebasing commits to make
them somewhat ordered for review, and i'm quite tired.
I do mind. this is not the sort of thing that can be done in a
follow up patch. If you don't want to d
LSTGM
https://codereview.appspot.com/35370043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/35370043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I would need, however, an appropriate new name for the property, and
the best I
can think of now is 'strength'.
'attack'?
https://codereview.appspot.com/26470047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/
On 2013/11/12 10:23:56, dak wrote:
a) we don't commit ourselves either way: it is undefined what a pure
duration
after an intervening chord will do.
b) just single pitches, no chords: that's what this patch proposes.
c) also chords: this patch needs more work, supporting code must be
wri
https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm
File scm/music-functions.scm (right):
https://codereview.appspot.com/22120043/diff/40001/scm/music-functions.scm#newcode780
scm/music-functions.scm:780: ;;; that don't interpret them is harmless.
does that mean that
2. 4
basically LGTM
https://codereview.appspot.com/14268043/diff/9001/lily/completion-note-heads-engraver.cc
File lily/completion-note-heads-engraver.cc (right):
https://codereview.appspot.com/14268043/diff/9001/lily/completion-note-heads-engraver.cc#newcode200
lily/completion-note-heads-engraver.cc
LGTM
https://codereview.appspot.com/14268043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, but then why not let the compiler generate the copy constructor?
https://codereview.appspot.com/12747043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2013/06/12 07:48:50, dak wrote:
On 2013/06/06 21:19:04, benko.pal wrote:
> follow up issue 3402 too
The delta from patch set 1 to patch set 2 looks decidedly strange. It
looks
like deleting most of the file.
um, yes. strange. the unified diff is as intended.
https://codereview.appsp
https://codereview.appspot.com/7538043/diff/5001/Documentation/notation/ancient.itely
File Documentation/notation/ancient.itely (right):
https://codereview.appspot.com/7538043/diff/5001/Documentation/notation/ancient.itely#newcode952
Documentation/notation/ancient.itely:952: @c @end example
On 2
some white mensural examples change, but that doesn't matter (if anybody
prefers not changing an example, I can fix those). I hope Greogrian
examples don't change - I don't know whether it would matter.
https://codereview.appspot.com/7538043/diff/5001/Documentation/notation/ancient.itely
File D
bwwtolilly is a typo, isn't it?
(diff view doesn't work for some reason.)
https://codereview.appspot.com/7098055/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/7180043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM; "not used by LilyPond" is really superior to "you don't need to
understand"!
https://codereview.appspot.com/7096052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/7101045/diff/1/lily/accidental-placement.cc
File lily/accidental-placement.cc (right):
https://codereview.appspot.com/7101045/diff/1/lily/accidental-placement.cc#newcode210
lily/accidental-placement.cc:210: int parity = 1;
could you use bool (or in an improved vers
good for a start but I have some problems with the duration parameter:
1.
{
\tuplet 3/2 { c8 c c c c c }
\tuplet 3/2 4 { c8 c c c c c }
\tuplet 3/2 { c8 c c c c c }
}
I found it ugly that the first and last input line are engraved
differently (i.e. duration has an effect outside of its tup
LGTM
https://codereview.appspot.com/7029043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/7017044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/7019045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
SGTM
python/midi.c should be removed (this may involve some make changes)
midi files are seen neither in the web interface, nor in the downloaded
patch.
https://codereview.appspot.com/7016046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
htt
LGTM
https://codereview.appspot.com/6924053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks!
https://codereview.appspot.com/6850073/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/6850073/diff/17001/input/regression/markup-rest-styles.ly
File input/regression/markup-rest-styles.ly (right):
https://codereview.appspot.com/6850073/diff/17001/input/regression/markup-rest-styles.ly#newcode18
input/regression/markup-rest-styles.ly:18: (symbo
LGTM
https://codereview.appspot.com/6854104/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2012/11/29 00:41:14, thomasmorley65 wrote:
On 2012/11/27 20:03:06, benko.pal wrote:
> > Did you had a look on the compiled output of the new reg-tests?
I did now, it's OK with me.
https://codereview.appspot.com/6850073/diff/7/input/regression/markup-rest-styles.ly
File input/regression/
On 2012/11/26 21:11:53, thomasmorley65 wrote:
On 2012/11/26 15:09:58, benko.pal wrote:
>
http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm
> File scm/define-markup-commands.scm (right):
>
>
http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands
So I'd suggest not treating the '-' at all (to make things not more
confusing than they already are) and letting the font backend sort
things out.
I concur.
http://codereview.appspot.com/6850073/diff/6004/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://coder
On 2012/11/25 23:03:43, thomasmorley65 wrote:
On 2012/11/21 08:05:09, benko.pal wrote:
[...]
> there are no separate glyphs for rests and multi measure rests: the
M in glyph
> names stands not for MultiMeasure, but for Minus.
Didn't know that.
> that makes for rewriting the
> cond below,
LGTM
http://codereview.appspot.com/6846083/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6850073/diff/9001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):
http://codereview.appspot.com/6850073/diff/9001/scm/define-markup-commands.scm#newcode3247
scm/define-markup-commands.scm:3247: "M"
there are no separate glyphs for rests a
On 2012/11/16 22:57:29, dak wrote:
On 2012/11/16 22:13:59, benko.pal wrote:
> LGTM in the sense that it won't make things worse; I've tried to
understand
> the code but failed, see below.
I have not actually tried to understand the code. I just added checks
for
existing array elements bef
LGTM in the sense that it won't make things worse; I've tried to
understand the code but failed, see below.
http://codereview.appspot.com/6810087/diff/2001/lily/simple-spacer.cc
File lily/simple-spacer.cc (right):
http://codereview.appspot.com/6810087/diff/2001/lily/simple-spacer.cc#newcode375
LGTM
http://codereview.appspot.com/6852052/diff/1/Documentation/notation/vocal.itely
File Documentation/notation/vocal.itely (left):
http://codereview.appspot.com/6852052/diff/1/Documentation/notation/vocal.itely#oldcode170
Documentation/notation/vocal.itely:170:
I'm sort of sorry to see this f
LGTM by reading only
http://codereview.appspot.com/6814115/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: Keith, dak,
http://codereview.appspot.com/6778050/diff/1001/lily/breathing-sign.cc
File lily/breathing-sign.cc (left):
http://codereview.appspot.com/6778050/diff/1001/lily/breathing-sign.cc#oldcode88
lily/breathing-sign.cc:88: int const int_dim = (int) ydim[i];
On 2012/10/27 19:36:21
hi Janek,
Pal, could you add some comments and a more descriptive commit
message? I see
the code, and it seems to make sense, but i don't understand the
"why's". For
example, why the parameters should be passed in a different way?
in C++ there should be a good reason to pass complex stru
Reviewers: ,
Message:
mensural-ligatures.ly is listed as changed - that is not surprising,
although I couldn't tell in advance _how_ it will change. what is a bit
more surprising that I can't tell even now, having seen the regtest
comparison.
Description:
prevent collision of ligatures and next
I don't like that: the patch manipulates a staff based on note head. it
also increments a hack.
have you tried something like
\override SpacingSpanner #'shortest-duration-space = #0
\override SpacingSpanner #'spacing-increment = #0
?
http://codereview.appspot.com/6684051/
_
having identical files in several directories looked suspicious to me,
but if that's the way to have it, then LGTM.
https://codereview.appspot.com/6567059/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/li
LGTM
https://codereview.appspot.com/6588049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
what about an example like
\afterGrace f1\glissando f'16
?
http://codereview.appspot.com/6567059/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1059
Documentation/notation/expressive.itely:1059:
@lilypond[verb
http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1074
Documentation/notation/expressive.itely:1074:
@lilypond[verb
http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely
File Documentation/notation/expressive.itely (right):
http://codereview.appspot.com/6529043/diff/1/Documentation/notation/expressive.itely#newcode1074
Documentation/notation/expressive.itely:1074:
@lilypond[verb
On 2012/09/14 06:53:47, Keith wrote:
On 2012/09/14 06:16:57, benko.pal wrote:
> main argument: I can't guess why the user chose a
> specific way of manipulating the staff and how (s)he
> interprets it,
If the user writes
> \override #'staff-space = #0.5
he wants to scale things.
If he write
I messed up something, the new patchset is at
http://codereview.appspot.com/6506090
http://codereview.appspot.com/6488097/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
sorry, I'm confused.
do we want to support
- NR 2.5.1 style 2-line percussion staves (setting both line-count and
staff-space to 2 instead of setting just line-positions to (-2 2))?
- default TabStaff's (even line-count, 1.5 staff-space)?
if we want to support both of those without changing dot s
results of the following searches were checked manually:
grep -rE -e 'const( +[a-zA-Z0-9_]*)? *, *$' .
grep -rE -e 'const( +[a-zA-Z0-9_]*)?( *,[^;]+)?\) *(const|= *0)? *;' .
http://codereview.appspot.com/6501096/
___
lilypond-devel mailing list
lilypo
Reviewers: ,
Message:
following up
http://codereview.appspot.com/6477062/#msg5
Description:
remove top-level const's from declarations
Please review this at http://codereview.appspot.com/6501096/
Affected files:
M flower/include/file-name.hh
M lily/include/constrained-breaking.hh
M lily/
LGTM
http://codereview.appspot.com/6496074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/6477062/diff/1/lily/include/skyline.hh
File lily/include/skyline.hh (right):
http://codereview.appspot.com/6477062/diff/1/lily/include/skyline.hh#newcode58
lily/include/skyline.hh:58: list *const result);
I'd like to see the const removed (top-level const on functio
LGTM
http://codereview.appspot.com/6477062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: marc, Keith, dak,
Message:
all changes in a single commit; I'm happy to resubmit it in four; I can
also push (after review and coutdown) in one or four or as you wish.
Description:
issue 2533 continued: fix problematic uses of line-count in bar-line
- modify regtests to show when to
I have now four commits: regtest changes plus one change
in three (sort of unrelated) functions each in bar-line.scm
(colon, extent and line-span computation).
what review process do you prefer/suggest?
one review per commit or review in one, push in four?
uploaded in a single commit for review:
the post-1320 version. Marc, please consider patch set 2 for bar-line
related changes.
http://codereview.appspot.com/6419064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Marc, please don't throw the whole 2533 issue stuff out; look at the
latest version at
http://codereview.appspot.com/6431044
in particular bar-line.cc and repeat-sign.ly.
I really don't mind if your patch goes before mine (it would even be
better - why push a change to a file that is to be thrown
regtests reorganized and explanations added
http://codereview.appspot.com/6419064/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: Keith, dak, marc,
Message:
when splitting the previous patch into smaller commits I added new
regtests and found further errors with bar-line.
to fix those there are some changes from the previous version:
- calc_bar_extent now not only shrinks the bar line, but can expand it
for narro
sorry, after juggling with git branches the new version is at
http://codereview.appspot.com/6419064
http://codereview.appspot.com/6431044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
patch enhanced to fix
http://code.google.com/p/lilypond/issues/detail?id=2648
if anyone wants to run regtests, please run both versions on the new
regtests.
I'd be happy to split the patch into several commits.
Description:
fix repeat-sign problems introduced with issue 2
Reviewers: ,
Message:
note that the newly added regtest shows some cases I'm not really sure
about: e.g. beaming/breaking of six eigth (or a4 a8 a8 a4) may have to
depend on whether it's a triplet or sextuplet.
Description:
make beams in 6/4, 9/4 and 12/4 behave like those in 3/4
Please review
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
scm/bar-line.scm:83: (define (make-colon-bar-line grob)
I'm afraid this defun doesn't match the relevant part of current
Bar_line::
http://codereview.appspot.com/6211047/diff/1/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/6211047/diff/1/lily/beam.cc#newcode1282
lily/beam.cc:1282: staff_span *= 0.5 / staff_space;
division is silly and works only because staff_space is generally 1.
http://codereview.a
Reviewers: ,
http://codereview.appspot.com/6211047/diff/1/lily/slur-scoring.cc
File lily/slur-scoring.cc (right):
http://codereview.appspot.com/6211047/diff/1/lily/slur-scoring.cc#newcode593
lily/slur-scoring.cc:593: && Staff_symbol_referencer::on_staff_line
(on_staff, (int) rint (pos)))
this c
http://codereview.appspot.com/6206057/diff/1/.mailmap
File .mailmap (right):
http://codereview.appspot.com/6206057/diff/1/.mailmap#newcode5
.mailmap:5: Benkő Pál
On 2012/05/13 07:45:51, dak wrote:
On 2012/05/13 07:13:08, janek wrote:
> It seems that this document is in the format ,
so here
1 - 100 of 128 matches
Mail list logo
