Reviewers: ,
Message:
Hey all,
Cleaning up my work on broken beam slopes, I found this bug in
calc_stem_info. It is a one liner, but it has a pretty significant
impact on kneed beams. The first stem info of all kneed beams is
currently being incorrectly calculated because it accessed the prope
Reviewers: ,
Message:
Hey all,
I think this convert-ly rule should encapsulate all changes
precipitating from the flag grob.
Please let me know if I have the version number wrong - I'm still kinda
fuzzy on what version numbers to use for these rules.
Cheers,
MS
Description:
Creates convert-ly
2011/9/18 :
> New patch set.
>
> After thinking about that during three weeks, I decided to remove the
> long tie and even reduce the length of the default tie. Janek, thank you
> for showing me that overshooting vowels was useless and maybe
> disturbing.
You're welcome :)
LGTM,
Janek
_
Official tests look good.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
sounds reasonable to me
http://codereview.appspot.com/5043047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Hey all,
This is now in a state where people can run regtests on it and comment
upon it.
There are a few things in the regtests that I still need to work on:
-) my feathered beam regtest has more vertical spacing between
systems...I still need to figure out why
-) i think the change in spanner-
hi Bertrand,
> The new mensural style introduced with commit
> 0dcc93c0a5a97d048db2f7631966f41ae0059ab5 created some ugliness's in
> mensural ligatures.
which commit is the patch supposed to apply to?
I couldn't apply it to my HEAD
f8a4491c571dc57c87aec33dc8e34c436e222537;
having applied it to 0d
Hi Pal!
I updated the patch.
This wasn't working since Werner's e10a13.
It couldn't be applied to 0dcc93: I forgot some files that I added in
0e31cd.
Bertrand
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.o
2011/9/18 Janek Warchoł :
> 2011/9/16 Aleksandr Andreev :
>>> If I recall correctly, undocumented glyphs will break the build (see
>>> Documentation/included/font-table.ly).
>>
>> Neil is correct, the documentation won't compile, it gives the
>> message: Unlisted glyphs in Documentation/included/fo
Another update that fixes some variable errors.
It now passes make.
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sep 18, 2011, at 9:52 PM, Janek Warchoł wrote:
> 2011/9/18 Janek Warchoł :
>> 2011/9/16 Aleksandr Andreev :
If I recall correctly, undocumented glyphs will break the build (see
Documentation/included/font-table.ly).
>>>
>>> Neil is correct, the documentation won't compile, it gives t
Reviewers: Bertrand Bordage,
Message:
On 2011/09/17 17:31:15, Bertrand Bordage wrote:
Hi Joe,
At last, a fix for that!
But this looks unfinished. Are you working on a solution that would
avoid
having to specify the X-extent?
That isn't actually mentioned in the issue report, but ok :)
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
- Original Message -
From: "Reinhold Kainhofer"
To: "LilyPond Development"
Sent: Saturday, September 17, 2011 3:53 PM
Subject: [PATCH] Fixing some docs build warnings
I'm currentlly trying to clean up some build warnings.
2) A normal "make" tries to load the translations for the g
MF code LGTM.
http://codereview.appspot.com/5030053/diff/9001/mf/parmesan-noteheads.mf
File mf/parmesan-noteheads.mf (right):
http://codereview.appspot.com/5030053/diff/9001/mf/parmesan-noteheads.mf#newcode497
mf/parmesan-noteheads.mf:497: draw_mensural_longa (m_longa_width,
m_holeheight, true,
Oh, yes. Thanks Werner, this is fixed.
http://codereview.appspot.com/5030053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I think LGTM, but it would be great if you'd add a regtest to
demonstrate what this patch is fixing. (i was going to write
"before/after pdfs attached to tracker issue would be priceless!" but
i've just saw that you added them - perfect!)
thanks,
Janek
http://codereview.appspot.com/5030053/dif
Hi,
i've noticed something strange in mensural-ligatures.ly: in the last
system, a flat symbol collides with the notes (attached). Should it
look like this?
I tried to determine when it was introduced, but i cannot open eps
files in Lilydev so all regtest archives from
http://lilypond.org/downloa
This collision has always been (2.12.3, 2.14.2...).
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2011/09/18 21:47:04, janek wrote:
I think LGTM, but it would be great if you'd add a regtest to
demonstrate what
this patch is fixing.
I don't think so. mensural-ligatures.ly contains every case fixed by
this patch.
If I make a regtest to show such tiny graphical differences, then we
would
Reviewers: J_lowe,
Message:
New patch-set uploaded for review.
Cheers
Ian
Description:
T1780 remove scheme format calls with no destination parameter -
deprecated in Guile V2
If possible, use (ly:format) for simple formatting strings to gain
performance.
Please review this at http://coderevie
Hi Ian,
I have some comments. The rest of the patch LGTM.
Regards,
Bertrand
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm
File scm/document-identifiers.scm (right):
http://codereview.appspot.com/4974078/diff/3001/scm/document-identifiers.scm#newcode31
scm/docume
On 9/18/11 2:28 PM, "joenee...@gmail.com" wrote:
> Reviewers: Bertrand Bordage,
>
> Message:
> On 2011/09/17 17:31:15, Bertrand Bordage wrote:
>> Hi Joe,
>
>> At last, a fix for that!
>> But this looks unfinished. Are you working on a solution that would
> avoid
>> having to specify the X-exte
As per comments by Neil, I removed the reg test file. Also made the
necessary changes to Documentation/included/font-table.ly
Also merged with Parmesan patch by Bertrand and resolved conflict.
http://codereview.appspot.com/4951062/
___
lilypond-devel
LGTM
http://codereview.appspot.com/4951062/diff/24001/mf/feta-kievan.mf
File mf/feta-kievan.mf (right):
http://codereview.appspot.com/4951062/diff/24001/mf/feta-kievan.mf#newcode52
mf/feta-kievan.mf:52: fill z1{dir 8.6} .. z2 .. z3
A minor thing: Please align this vertically (and at similar pla
Reviewers: ,
Message:
Hey all,
While working on flags, I noticed that horizontal spacing changes when a
grob is part of a NoteColumn's element list.
I went back to StemTremolos and tested this out: run the code below with
and without this patch:
\relative c'' {
\time 8/4
\autoBeamOff
\ov
On Sun, Sep 18, 2011 at 5:41 AM, wrote:
> Cleaning up my work on broken beam slopes, I found this bug in
> calc_stem_info. It is a one liner, but it has a pretty significant
> impact on kneed beams. The first stem info of all kneed beams is
> currently being incorrectly calculated because it a
On Sep 19, 2011, at 7:50 AM, Han-Wen Nienhuys wrote:
> On Sun, Sep 18, 2011 at 5:41 AM, wrote:
>
>> Cleaning up my work on broken beam slopes, I found this bug in
>> calc_stem_info. It is a one liner, but it has a pretty significant
>> impact on kneed beams. The first stem info of all kneed b
28 matches
Mail list logo
