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
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/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
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,
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
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
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
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/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
https://codereview.appspot.com/576610043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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/29 06:43:19, hanwenn wrote:
> score performer
removed unused: looks good.
changing references to pointers: looks BD.
https://codereview.appspot.com/577440044/
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
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
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: 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
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
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
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
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:
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
LGTM
http://codereview.appspot.com/6477062/
___
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/6496074/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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/
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
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
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
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
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
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
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
LGTM
https://codereview.appspot.com/6588049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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/
_
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
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: 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
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
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 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
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
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
LGTM
http://codereview.appspot.com/6846083/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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,
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/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
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/
LGTM
https://codereview.appspot.com/6854104/
___
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, 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/6924053/
___
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/7019045/
___
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/7029043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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
LGTM
https://codereview.appspot.com/7180043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
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
hi Bertrand,
Another update that fixes some variable errors.
It now passes make.
this is ok, passes apply, make and all my test; thanks!
p
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.g
On 2011/09/18 19:55:47, Bertrand Bordage wrote:
Another update that fixes some variable errors.
It now passes make.
thanks Bertrand, this is great work;
I can now print flexae just the default way!
(so long I had to use non-default viewers and lpr commands.)
p
http://codereview.appspot.com/50
Reviewers: ,
Message:
hi all,
if I extend the staff by a line, pitched rests appear shifted by half a
line (thus half rests look like whole rests and vice versa).
this patch is a quick fix for that.
I feel the line-positions and line-count properties of Staff are badly
tangled; I intend to work
patch rebased
http://codereview.appspot.com/5434061/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
hi Aleksandr,
I've uploaded a patch that gets at Vaticana and Mensural as well. It
seems that
"Beam_performer" would not be necessary for the two, but I don't know
about
"Tie_performer" and "Slur_performer". It would probably be good for
someone who
knows more than me about Gregorian chant
Reviewers: ,
Message:
this patch makes staff_radius work in cases when line-positions is
overridden. so long staff_radius assumed overriding at most line-count.
http://codereview.appspot.com/6202048/diff/1/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (left):
http://codereview.appspot.co
this patch makes staff_radius work in cases when line-positions is
overridden.
so long staff_radius assumed overriding at most line-count.
sorry, I forgot to mention that
- staff-radius behaved incorrectly also when staff-space is overridden
- there's one slight difference in the regression te
On 2012/05/07 18:25:35, Graham Percival wrote:
looks like this simplifies things, which is always nice to see.
http://codereview.appspot.com/6202048/diff/1/lily/slur-configuration.cc
File lily/slur-configuration.cc (right):
http://codereview.appspot.com/6202048/diff/1/lily/slur-configurati
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
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/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
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::
Reviewers: ,
Message:
here is the patch set I hinted at several times:
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00212.html
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00097.html
some changes are just very slightly related:
mf/parmesan-custodes.mf just makes cus
One thing I forgot to mention: I've also rewritten dot handling within
ligatures. The old code
- didn't avoid staff lines
- didn't conform actual usage: dotting notes above is not a practice,
only if they are first within a flexa, see examples in
http://anaigeon.free.fr/mes_facs/fsbarb.jpg
http:/
Reviewers: ,
Message:
patchset related to
http://code.google.com/p/lilypond/issues/detail?id=1268
as outlined in
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00225.html
note that this is the first time I touch Python (for sure) and the
documentation (possibly).
Description:
remov
new patch set up, thanks for reviewing. answers below.
On 2011/01/21 13:50:22, Graham Percival wrote:
The python bits looked fine. I tried a regtest comparison and didn't
see any
change at all other than test-output-distance, so maybe something went
wrong.
Should I see any difference in th
On 2011/01/23 15:00:28, Graham Percival wrote:
Passes regtests, but a few minor nitpicks.
thanks, Graham; all observations implemented.
http://codereview.appspot.com/4025044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.or
new patchset up.
please advise me about regression tests: can I modify ligatures within
mensural-ligatures.ly? if not, can I add new ones to the same file?
http://codereview.appspot.com/3797046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
all suggestions implemented, thanks all!
http://codereview.appspot.com/4025044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
and a try at Changes.
Description:
enhance ligature test with new features
Please review this at http://codereview.appspot.com/3989049/
Affected files:
M Documentation/changes.tely
M input/regression/mensural-ligatures.ly
___
sorry Graham; next time I'll try to remember to open a new issue after
pushing.
p
http://codereview.appspot.com/3989049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: ,
Message:
following up on modal transformation
Description:
exact inversion
Please review this at http://codereview.appspot.com/4173065/
Affected files:
M Documentation/notation/pitches.itely
M input/regression/modal-transforms.ly
M ly/music-functions-init.ly
M scm/modal-tr
Just minor stuff for the NR.
all implemented.
http://codereview.appspot.com/4173065/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/4536068/diff/1/scm/define-grobs.scm
File scm/define-grobs.scm (right):
http://codereview.appspot.com/4536068/diff/1/scm/define-grobs.scm#newcode1305
scm/define-grobs.scm:1305: (duration-log-list . (0 -1 -2 -3))
On 2011/05/18 13:54:43, Bertrand Bordage wrote:
Just o
http://codereview.appspot.com/4490045/diff/12001/lily/completion-note-heads-engraver.cc
File lily/completion-note-heads-engraver.cc (right):
http://codereview.appspot.com/4490045/diff/12001/lily/completion-note-heads-engraver.cc#newcode207
lily/completion-note-heads-engraver.cc:207:
event->set_p
On 2011/05/29 18:36:20, Janek Warchol wrote:
New patch set from Karin uploaded.
thanks, looks marvelous to me.
Pal
http://codereview.appspot.com/4490045/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/
hi Bertrand,
the patch is correct, AFAICS; see some minor improvements below.
minor concerns (which shouldn't delay acception):
1. about the very existence of usable-duration-logs -
ok, it's generic, but who uses this genericity?
is it not always (0 -1 -2 -3)?
is it not always a range
hi Bertrand,
(I'm not a grand-master, :( )
good that you caught the problem with hole in usable-duration-logs, but,
I think, that makes more comment necessary, see below.
all reviewers: is there a convention about using assertions in C++ code?
http://codereview.appspot.com/4536068/diff/55001/
there are problems: the patch as is fails the mensural-ligatures
regtest. see below.
p
http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc
File lily/mensural-ligature.cc (right):
http://codereview.appspot.com/4639065/diff/13002/lily/mensural-ligature.cc#newcode147
lily/
hi Bertrand,
What has been done for Petrucci/mensural/neomensural:
* Stems centered around the attachment point.
* Attachment point lowered.
* Brevis/longa/maxima pointing downward.
* Use the left-stemmed longa in ligatures.
exactly what is this last one?
p
http://codereview.appspot.com/4639
hi Bertrand,
sorry, I messed up my build last time, and the mensural-ligatures.ly
regtest is still bad. look at the first row: the last LB and last SS
are indistinguishable. 2.14 is right.
all: what would be the good place for the ligature description in the
second attachment of
http://lists.
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
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
LGTM
https://codereview.appspot.com/14268043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
1 - 100 of 128 matches
Mail list logo
