Yeah! I've just uploaded an update to Sebastiano's `cd' package for
LaTeX, and I was also bitten by the change of his e-mail address...
AFAIK, the URL change is out of Sebastiano's control.
Thanks for working on this.
https://codereview.appspot.com/102410043/
[I mean `uploaded' to CTAN, of course - this is not related to
lilypond.]
https://codereview.appspot.com/102410043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/108110044/diff/1/input/regression/unassociated-lyrics-alignment.ly
File input/regression/unassociated-lyrics-alignment.ly (right):
https://codereview.appspot.com/108110044/diff/1/input/regression/unassociated-lyrics-alignment.ly#newcode5
LGTM, thanks!
https://codereview.appspot.com/108110044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/108110044/diff/60001/lily/lyric-engraver.cc
File lily/lyric-engraver.cc (right):
https://codereview.appspot.com/108110044/diff/60001/lily/lyric-engraver.cc#newcode187
lily/lyric-engraver.cc:187: Syllable will be attached to a PaperColumn
instead.));
I suggest
Or maybe some cpp macro trickery improves the legibility.
https://codereview.appspot.com/106190043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM (without any testing).
https://codereview.appspot.com/105410046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/110540043/diff/1/scm/modal-transforms.scm
File scm/modal-transforms.scm (right):
https://codereview.appspot.com/110540043/diff/1/scm/modal-transforms.scm#newcode134
scm/modal-transforms.scm:134: \n(see).
@code{transposer-factory}
Thanks. LGTM.
https://codereview.appspot.com/110540043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/118950043/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/118950043/diff/1/scm/define-grob-properties.scm#newcode814
scm/define-grob-properties.scm:814: Value @w{@code{-1}} means left
LGTM.
https://codereview.appspot.com/123160043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/124240043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix incredibly reckless context/grob property mixup in event-listener
I would rather call this clueless :-)
https://codereview.appspot.com/126280043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I don't actually understand the code, but I like the encapsulation, so:
LGTM.
https://codereview.appspot.com/131770043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Very nice! I guess it makes sense to actually provide `\boring'
and `\tricky' with better names...
https://codereview.appspot.com/131970043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM. This is the kind of patches that I would immediately apply to
staging, not wasting a whole build cycle...
https://codereview.appspot.com/127700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
LGTM. Very nice! This indeed feels more C++ now.
https://codereview.appspot.com/135240043/diff/20001/scripts/auxiliar/smob-convert.sh
File scripts/auxiliar/smob-convert.sh (right):
https://codereview.appspot.com/135240043/diff/20001/scripts/auxiliar/smob-convert.sh#newcode2
LGTM.
https://codereview.appspot.com/140170043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/139190044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks.
https://codereview.appspot.com/138150043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, from visual inspection only :-)
https://codereview.appspot.com/152370043/diff/1/lily/include/book.hh
File lily/include/book.hh (right):
https://codereview.appspot.com/152370043/diff/1/lily/include/book.hh#newcode31
lily/include/book.hh:31: typedef SmobBook base_type;
I would insert an
Very nice! Thanks for implementing this feature. LGTM.
https://codereview.appspot.com/159050043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/163520043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/167040043/diff/1/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):
https://codereview.appspot.com/167040043/diff/1/lily/side-position-interface.cc#newcode383
lily/side-position-interface.cc:383: /* If we are closer to the staff
LGTM.
https://codereview.appspot.com/168700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/174230043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Aaand another LGTM :-)
https://codereview.appspot.com/65260044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/134220043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/179320043/diff/1/lily/beam.cc
File lily/beam.cc (right):
https://codereview.appspot.com/179320043/diff/1/lily/beam.cc#newcode1357
lily/beam.cc:1357: /* Estimate the closest beam to be four positions
away from the heads.. */
I always notice the most
LGTM, save a small remark.
https://codereview.appspot.com/173280043/diff/40001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):
https://codereview.appspot.com/173280043/diff/40001/scm/define-grob-properties.scm#newcode1287
scm/define-grob-properties.scm:1287:
LGTM, thanks!
https://codereview.appspot.com/177640043/diff/1/mf/feta-rests.mf
File mf/feta-rests.mf (right):
https://codereview.appspot.com/177640043/diff/1/mf/feta-rests.mf#newcode416
mf/feta-rests.mf:416: labels (9, 12);
Please remove those two label statements. You are rotating and
https://codereview.appspot.com/177640043/diff/20001/mf/feta-rests.mf
File mf/feta-rests.mf (right):
https://codereview.appspot.com/177640043/diff/20001/mf/feta-rests.mf#newcode438
mf/feta-rests.mf:438: rest := rest xscaled -1 shifted (w, 0);
Please use tabs for indentation
Some nits. Thanks for adding this!
https://codereview.appspot.com/187140044/diff/20001/lily/separation-item.cc
File lily/separation-item.cc (right):
https://codereview.appspot.com/187140044/diff/20001/lily/separation-item.cc#newcode190
lily/separation-item.cc:190: Draws the
LGTM
https://codereview.appspot.com/186530043/diff/1/lily/skyline.cc
File lily/skyline.cc (right):
https://codereview.appspot.com/186530043/diff/1/lily/skyline.cc#newcode249
lily/skyline.cc:249: printf (We are here);
Debugging remnants?
https://codereview.appspot.com/186530043/
LGTM. Maybe it makes sense to commit the removal of the `deholify'
stuff separately.
https://codereview.appspot.com/186530043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/186570043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ah, nice! I wasn't aware of this script. Thanks for mentioning it.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/201140043/diff/20001/lily/spanner.cc
File lily/spanner.cc (right):
https://codereview.appspot.com/201140043/diff/20001/lily/spanner.cc#newcode394
lily/spanner.cc:394: /*
Minor nit: Please use spaces, not tabs.
https://codereview.appspot.com/201140043/
LGTM.
https://codereview.appspot.com/201140043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. It would be nice if David's checker script could be added, too.
https://codereview.appspot.com/199460043/diff/20001/ly/performer-init.ly
File ly/performer-init.ly (right):
https://codereview.appspot.com/199460043/diff/20001/ly/performer-init.ly#newcode174
ly/performer-init.ly:174:
Thank *you* for your hard work. Here's the next round of comments.
https://codereview.appspot.com/194090043/diff/40001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
David's concerns are very specific to the Lilypond documentation, not
covering the general case. Many programs simply can't process PS output
at all, so the suggestion to collect PS data that gets reduced later on
is not applicable.
The only valid alternative is to make Lilypond natively
Well, we get a large size reduction even if we don't use pdfsizeopt!
Using this program is an extra bonus but not mandatory. And you are
right, I hope that Péter fixes the reported issues, provided someone is
going to add them to the bug tracker (which hasn't happened yet, looking
at
LGTM, thanks!
https://codereview.appspot.com/196260043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/01/27 07:26:53, dak wrote:
It seems to me like this number-pair consists of two settings that
would almost
always be adjusted independently. Wouldn't it make more sense to make
a
separate property here? That way, the user would not need to remember
and
restate the setting he is
https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly
File input/regression/script-shift.ly (right):
https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly#newcode6
input/regression/script-shift.ly:6: means centered on the stem.)
I'm
LGTM.
https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly
File input/regression/script-shift.ly (right):
https://codereview.appspot.com/196260043/diff/20001/input/regression/script-shift.ly#newcode6
input/regression/script-shift.ly:6: means centered on the
LGTM, thanks! I only have some minor comments regarding improved
legibility of the source code.
https://codereview.appspot.com/194090043/diff/1/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely
File Documentation/de/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/de/usage/running.itely#newcode160
Documentation/de/usage/running.itely:160: pdftex-,
Thanks for your help and assistance!
For better orientation, please reformat this to have a fixed number
of entries per line (I suggest 4 items),
I did 3 items maximum and kept things within the line length.
Basically, this is fine. However, three is incommensurable to 16, ...
Werner,
I don't object to the name! I only state that the option's name doesn't
have an explanation in the English documentation, and I think it would
be good if it gets added.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely
File Documentation/usage/running.itely (right):
https://codereview.appspot.com/194090043/diff/20001/Documentation/usage/running.itely#newcode187
Documentation/usage/running.itely:187: font data which can make
Hmm. I can't find in your description that `--bigpdfs' creates *big*
output files that get later reduced to small one by running ghostscript
again.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
Knut, *your* patch set has this, but James's version (in patch set 2)
misses it.
https://codereview.appspot.com/194090043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/219780044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/217720043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Any idea how to find it?
https://codereview.appspot.com/217720043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Thanks for the test diffs. Looking at the regression tests, I see some
degradations.
. The second beam in `grace-start' is too far offset from the staff.
Ditto for grace-`stem-length' and others. Note that I got similar
glitches earlier too in my real-life scores but was never be able to
LGTM.
https://codereview.appspot.com/206370043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/226700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/226700043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Nice! However, I second David's concern: Please use
\absolute pitch
instead of
\absolute number
https://codereview.appspot.com/235010043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
I also favour
\absolute c'' { ... }
in Keith's original interpretation. However, I suggest to document
somewhere that only letter `c' is supported.
https://codereview.appspot.com/235010043/diff/60001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
LGTM.
https://codereview.appspot.com/235090043/diff/1/input/regression/stencil-scale.ly
File input/regression/stencil-scale.ly (right):
https://codereview.appspot.com/235090043/diff/1/input/regression/stencil-scale.ly#newcode8
input/regression/stencil-scale.ly:8: its bounding box.)
Please use
https://codereview.appspot.com/235090043/diff/40001/scm/stencil.scm
File scm/stencil.scm (right):
https://codereview.appspot.com/235090043/diff/40001/scm/stencil.scm#newcode668
scm/stencil.scm:668: An @var{axis} of Y or 1 will flip it vertically.
What about:
Value @code{X} (or @code{0}) for
LGTM.
https://codereview.appspot.com/234260043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
https://codereview.appspot.com/233300043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/233230044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
* I had a further look at the short stems, and should have fixed
more cases by disabling forbidden beam quanting in case of grace
notes.
Yes, everything looks OK now, thanks.
* magnifyMusic: can you show examples of what music at 50% scale
should look like in print?
No, I can't.
LGTM.
https://codereview.appspot.com/235090043/diff/60001/input/regression/stencil-flip.ly
File input/regression/stencil-flip.ly (right):
https://codereview.appspot.com/235090043/diff/60001/input/regression/stencil-flip.ly#newcode1
input/regression/stencil-flip.ly:1: \version 2.19.19
I would
The best choice seems to be \fixed, both for the good fit
of the meaning of the word to the command, and because it
is relatively easy to type. If we allow its reference
pitch to be optional, then the relatively new command
\absolute is the same as \fixed with no reference pitch,
and we can
Letting PostScript ask for Helvetica which will let GhostScript
fall back to the URW version when the original Helvetica is not
available. If I understand correctly, we currently ask for and
embed the URW version. But maybe printers have their own way
to resubstitute the original. No idea.
Thanks again for the regtests. All my previous comments still hold,
unfortunately.
https://codereview.appspot.com/214250043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Wouldn't it make more sense to have one setting for all
of the included fonts? Are there really circumstances
where we can expect all of these to be different?
Probably not. I think that the patch is a proof of concept, and we
should comment on it.
https://codereview.appspot.com/224800043/
I like the current overall look for _this_ choice of fonts
better afterwards as compared to before, even though the C
glyph has a more conspicuous rounding and the G glyph has
the well-known somewhat poignant Helvetica shape.
Yes, it's more consistent. On the other hand, I very much dislike
Nice! LGTM.
https://codereview.appspot.com/241340043/diff/1/lily/font-config.cc
File lily/font-config.cc (right):
https://codereview.appspot.com/241340043/diff/1/lily/font-config.cc#newcode60
lily/font-config.cc:60: confs.push_back (lilypond_datadir +
/fonts/lilypond-fonts.conf);
This line
https://codereview.appspot.com/241340043/diff/1/lily/font-config.cc
File lily/font-config.cc (right):
https://codereview.appspot.com/241340043/diff/1/lily/font-config.cc#newcode62
lily/font-config.cc:62: for (vsize i = 0; i confs.size (); i++)
... do we have a loop here?
I mean: *Why* do we
LGTM
https://codereview.appspot.com/243310043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks!
https://codereview.appspot.com/241340043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM. Funny that noone has every tried to simplify this...
https://codereview.appspot.com/252810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks.
https://codereview.appspot.com/261980044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Oh, I haven't meant that you should reformat everything but just the
code you are actually modifying! But thanks anyway.
For long names I suggest a formatting like this
Grob::maybe_pure_internal_simple_skylines_from_extents(
foo arg1,
bar arg2,
...)
to avoid exactly the problem
LGTM
https://codereview.appspot.com/246590043/diff/20001/lily/stencil-integral.cc
File lily/stencil-integral.cc (right):
https://codereview.appspot.com/246590043/diff/20001/lily/stencil-integral.cc#newcode62
lily/stencil-integral.cc:62: void create_path_cap (vectorBox boxes,
LGTM
https://codereview.appspot.com/258030043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I don't have enough knowledge for a LGTM, but reading the source code I
noticed one detail...
https://codereview.appspot.com/256230045/diff/1/lily/performance.cc
File lily/performance.cc (right):
https://codereview.appspot.com/256230045/diff/1/lily/performance.cc#newcode92
LGTM, thanks.
https://codereview.appspot.com/255610043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/258160043/diff/1/lily/font-config.cc
File lily/font-config.cc (right):
https://codereview.appspot.com/258160043/diff/1/lily/font-config.cc#newcode43
lily/font-config.cc:43: /* Create an empty configureation */
s/configureation/configuration/
LGTM
https://codereview.appspot.com/258190043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
This is a good idea. LGTM.
https://codereview.appspot.com/263730043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks.
https://codereview.appspot.com/258190043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM, thanks!
https://codereview.appspot.com/258250043/diff/1/tex/lilypond.map.in
File tex/lilypond.map.in (left):
https://codereview.appspot.com/258250043/diff/1/tex/lilypond.map.in#oldcode1
tex/lilypond.map.in:1: pncr8r CenturySchL-Roma @NCSB_DIR@/c059013l.pfb
This is now an empty file...
+1
https://codereview.appspot.com/269530043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/264080043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
My main purpose was the distinction between the TTC and OTC.
So this patch cannot distinguish between the PFA and PFB.
OK, but IMHO we should get rid of being dependent on the file
name suffix.
I'm trying the following `font-file-as-ps-string' with this
Patch Set 2.
Hmm, this looks like the
You were faster than me :-)
LGTM, but note that FreeType's `FT_Get_Font_Format` doesn't really
return the font format but the name of the module used to handle a font.
In particular, it doesn't make a difference between PFA and PFB.
While I haven't started coding yet, I've played around to
LGTM.
https://codereview.appspot.com/293710043/diff/1/lily/pfb-scheme.cc
File lily/pfb-scheme.cc (right):
https://codereview.appspot.com/293710043/diff/1/lily/pfb-scheme.cc#newcode13
lily/pfb-scheme.cc:13: " to PFA format. If the file is already in PFA
format,"
Please two spaces after a full
LGTM – please update the title of this Rietveld issue
https://codereview.appspot.com/300280043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/299200043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reviewers: dak,
Message:
Ok, running the script with just --version or --help does indeed not
need the midi module.
Yep.
This is ugly as whatever but likely will do the trick.
:-) Interestingly, I haven't find out yet how `midi.c' gets compiled
at all; I can't find any trace of it in the
Werner, do you think you can push a fixed version?
Done. For me, `make test` succeeded.
https://codereview.appspot.com/297420043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
201 - 300 of 713 matches
Mail list logo