Gets first stem-info of a kneed-beam right (issue 5043047)
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 property
directly instead of using Beam::is_knee. This fixes that problem.
I'd like to push it directly to current master, as it is a one liner,
passes regtests (it changes several files that were incorrect before),
and I can't move on with my work on the other patch until this is sorted
out. I'm gonna hold off until I get some responses back, though, to
make sure that people are cool with this.
Cheers,
MS
Description:
Gets first stem-info of a kneed-beam right
Please review this at http://codereview.appspot.com/5043047/
Affected files:
M lily/stem.cc
Index: lily/stem.cc
diff --git a/lily/stem.cc b/lily/stem.cc
index
6575914789de9e84c7e9164592d82eda600b6319..f6bedcfd95461992e1e2498b34b055c8e1c0a0fb
100644
--- a/lily/stem.cc
+++ b/lily/stem.cc
@@ -988,7 +988,7 @@ Stem::calc_stem_info (SCM smob)
Also, not for knees. Seems to be a good thing. */
bool no_extend = to_boolean (me-get_property (no-stem-extend));
- bool is_knee = to_boolean (beam-get_property (knee));
+ bool is_knee = Beam::is_knee (beam);
if (!no_extend !is_knee)
{
/* Highest beam of (UP) beam must never be lower than middle
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Creates convert-ly rules for flag syntax changes (issue 5050046)
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 rules for flag syntax changes Please review this at http://codereview.appspot.com/5050046/ Affected files: M python/convertrules.py Index: python/convertrules.py diff --git a/python/convertrules.py b/python/convertrules.py index b1e3fefd453112ca010cc1c00144874f818872cc..1f4e8bb0df97ff641eeb2c0590dd260d6fc7f2e7 100644 --- a/python/convertrules.py +++ b/python/convertrules.py @@ -3232,6 +3232,15 @@ def conv (str): stderr_write (UPDATE_MANUALLY) return str +@rule ((2, 15, 10), + _ (Creation of a Flag grob and moving of certain Stem properties to this grob)) +def conv (str): +str = re.sub (rStem\s+#'flag-style, rFlag #'style, str) +str = re.sub (rStem\s+#'stroke-style, rFlag #'stroke-style, str) +str = re.sub (rStem\s+#'flag, rFlag #'print, str) +str = re.sub (rStem\s+#'transparent\s*=\s*##t, rStem #'transparent = ##t \\override Flag #'transparent = ##t, str) +return str + # Guidelines to write rules (please keep this at the end of this file) # ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New short and long lyric ties. (issue 4912041)
2011/9/18 bordage.bertr...@gmail.com: 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
2.15.11 regtest
Official tests look good. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets first stem-info of a kneed-beam right (issue 5043047)
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
Re: Sketch for broken beams with consistent slopes (issue 4961041)
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-break-overshoot is kinda cool, but i need to figure out a way to scrub the warning message. -) beam-slope-stemlet, perennial thorn in my side, shows a change that i need to scrub. What I'd appreciate from people at this stage of the game are four things: 1) Regtest running to confirm that my checks are valid. 2) General comments on design (properties I could add to make it more tweakable, etc.). 3) A critical eye at dividing by staff_space. You'll see that in beam-quanting.cc, there are several Real values that are divided by staff_space. I've avoided doing this in all the new stuff I've added, and it seems to have had no effect, but if someone could create a good test file I could use to check the effects of staff space on beam positions, I'd be much obliged. Or, alternatively, for someone who gets staff_space better than I do, if they spot any obvious problems, please let me know. 4) Figuring out cases that break this code. I'm sure that crazy broken cross staff beams lead to odd output, but I'll deal with esoteric cross-staff stuff in another patch if I need to. Mostly, please try to think of odd cases that may cause my work to segfault or return bad beams. Thank you all! Cheers, MS http://codereview.appspot.com/4961041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
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 0dcc93 it produced empty longae in ligatures, after removing the build directory even make failed. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
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.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1873 in lilypond: Added glyphs for Kievan Notation
2011/9/18 Janek Warchoł janek.lilyp...@gmail.com: 2011/9/16 Aleksandr Andreev aleksandr.andr...@gmail.com: 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/font-table.ly I've added the necessary code to font-table.ly However, my documentation still won't compile. I get the following message: cp -p web.texi out-www/web.texi cp: cannot stat `web.texi': No such file or directory make[3]: *** [out-www/web.texi] Error 1 make[3]: Leaving directory `/home/sasha/lilypond-git/build/Documentation/de' make[2]: *** [WWW-1] Error 2 rm out-www/weblinks.itexi make[2]: Leaving directory `/home/sasha/lilypond-git/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/sasha/lilypond-git/build' make: *** [doc-stage-1] Error 2 Doesn't look like this has something to do with the Kievan glyphs. What is web.texi? web.texi is a file in Documentation/ directory, but I don't know why such an error could appear... Oh, i've now realized that you've sent this e-mail just to Neil and me, so I'm forwarding it it to the whole -devel mailing list. I'm sure someone there will be able to help you, Bah. I wrote that i forward and i didn't forward, sorry... Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
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.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fixing some docs build warnings
- Original Message - From: Reinhold Kainhofer reinh...@kainhofer.com To: LilyPond Development lilypond-devel@gnu.org 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 gettext domain lilypond-doc from the directory /home/reinhold/lilypond/lilypond/Documentation/po/out-www As they are not created during a normal build, we get one warning for each file processed: langdefs.py: warning: lilypond-doc gettext domain not found. Can't we add the lilypond-doc gettext creation to the begin of a normal build, too? I think this is somewhat non-trivial, but would be happy to look at how it could be done. However - if you know a simple way, from my point of view please feel free to propose a patch. If not, I'll dive deeper into the build system. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
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/diff/9001/lily/mensural-ligature.cc File lily/mensural-ligature.cc (right): http://codereview.appspot.com/5030053/diff/9001/lily/mensural-ligature.cc#newcode79 lily/mensural-ligature.cc:79: stencil = Lookup::beam (corrected_slope, width * 0.5, staff_space, blotdiameter); What does this do? (sorry for a stupid question) http://codereview.appspot.com/5030053/diff/9001/lily/mensural-ligature.cc#newcode201 lily/mensural-ligature.cc:201: (noteheads.sM2ligmensural).extent (Y_AXIS).length () * 0.5 I don't get it - why is this commented? http://codereview.appspot.com/5030053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
possible bad output in mensural-ligatures.ly
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/download/binaries/test-output/ are useless for me... cheers, Janek attachment: flat and ligature collision.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
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 need to do the same thing for almost every graphical object... http://codereview.appspot.com/5030053/diff/9001/lily/mensural-ligature.cc#newcode79 lily/mensural-ligature.cc:79: stencil = Lookup::beam (corrected_slope, width * 0.5, staff_space, blotdiameter); What does this do? (sorry for a stupid question) This is making a beam with round corners (blotdiameter is the radius of the round corner). These beams are used to represent the flexa (the big 'slide' at the end of the before/after PNGs). http://codereview.appspot.com/5030053/diff/9001/lily/mensural-ligature.cc#newcode201 lily/mensural-ligature.cc:201: (noteheads.sM2ligmensural).extent (Y_AXIS).length () * 0.5 I don't get it - why is this commented? Because the stems of these noteheads are not inside their Y-extent. This comment shows how this should ideally work. http://codereview.appspot.com/5030053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
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/document-identifiers.scm:31: Why a new line? http://codereview.appspot.com/4974078/diff/3001/scm/lily.scm File scm/lily.scm (right): http://codereview.appspot.com/4974078/diff/3001/scm/lily.scm#newcode353 scm/lily.scm:353: (ly:format Err... Why is this required? Be careful with the indentation: there shouldn't be tabulators. http://codereview.appspot.com/4974078/diff/3001/scripts/musicxml2ly.py File scripts/musicxml2ly.py (right): http://codereview.appspot.com/4974078/diff/3001/scripts/musicxml2ly.py#newcode71 scripts/musicxml2ly.py:71: (ly:format #f ~a:~a den num))) #f? http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 155: parentheses include accidentals and dots. (issue 5047048)
On 9/18/11 2:28 PM, joenee...@gmail.com 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-extent? That isn't actually mentioned in the issue report, but ok :) A fix that calculates the font size of the ParenthesesItem according to the Y-extent of the parenthesized grobs would also be awesome :) Yes, there's another bug report for that. I haven't attempted it yet. We have a parenthesize scheme function that draws a bezier parenthesis that matches the object being parenthesized -- see parenthesize-stencil. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
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 places
also); this is, the indentation here consists of a tab and some space
characters:
fill z1 .. z2 ..z3
z4 .. z5 .. z6
...
Maybe you call this weird, but it helps reading the code, at least for
me :-)
http://codereview.appspot.com/4951062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets first stem-info of a kneed-beam right (issue 5043047)
On Sun, Sep 18, 2011 at 5:41 AM, mts...@gmail.com 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 accessed the property directly instead of using Beam::is_knee. This fixes that problem. I'd like to push it directly to current master, as it is a one liner, passes regtests (it changes several files that were incorrect before), and I can't move on with my work on the other patch until this is sorted out. I'm gonna hold off until I get some responses back, though, to make sure that people are cool with this. Shouldnt this just use a callback to calc is-knee ? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets first stem-info of a kneed-beam right (issue 5043047)
On Sep 19, 2011, at 7:50 AM, Han-Wen Nienhuys wrote: On Sun, Sep 18, 2011 at 5:41 AM, mts...@gmail.com 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 accessed the property directly instead of using Beam::is_knee. This fixes that problem. I'd like to push it directly to current master, as it is a one liner, passes regtests (it changes several files that were incorrect before), and I can't move on with my work on the other patch until this is sorted out. I'm gonna hold off until I get some responses back, though, to make sure that people are cool with this. Shouldnt this just use a callback to calc is-knee ? Possible - I'm not really sure why a callback currently doesn't exist for kneed beams. It seems like Beam::is_knee could easily be turned into a callback. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
