Re: Fixes heights and pure heights of stems. (issue 4898044)

On Mar 27, 2012, at 9:21 AM, Keith OHara wrote: > It seems that the /begin/ positions, the positions of the stem-ends attached > to the note heads, should be calculated the old way whether the beam > placement has been determined or not, so I'm inclined to remove if() above, > removing the need

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Mon, 26 Mar 2012 23:14:15 -0700, Mike Solomon wrote: The code in lily/note-collision.cc:219 needs an update to adjust the stem beginning (issue 2441). I tried but I can't find the "pure callback for stem beginnings". ly:stem::pure-calc-stem-begin-position Okay, it is actually the not-

Re: Fixes heights and pure heights of stems. (issue 4898044)

> Mike, > The code in lily/note-collision.cc:219 needs an update to adjust the > stem beginning (issue 2441). I tried but I can't find the "pure > callback for stem beginnings". > ly:stem::pure-calc-stem-begin-position Lemme know if I can be of help w/ fixing this! Cheers, MS ___

Re: Fixes heights and pure heights of stems. (issue 4898044)

On 2011/08/14 16:25:28, MikeSol wrote: Hey all, This patch fixes a bug in LilyPond that has nagged me for some time: incorrect heights and pure heights for stems. Also, the Stem grob's property list is cleaned up. It looses three confusing properties: length, stem-begin-position, and s

Re: Fixes heights and pure heights of stems. (issue 4898044)

Pushed as aaacb8cdd5bc029a8d0c87f90b817d97fcd5ad80. Thanks to everyone for their help! Cheers, MS http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Aug 24, 2011, at 1:46 PM, Janek Warchoł wrote: > 2011/8/24 Mike Solomon : >> On Aug 24, 2011, at 12:09 AM, Janek Warchoł wrote: >> >>> 2011/8/16 Han-Wen Nienhuys : #2) sounds neat, but maybe Janek (who has spent some time messing around with flags) wants to weigh in. >>> >>> As i'v

Re: Fixes heights and pure heights of stems. (issue 4898044)

2011/8/24 Mike Solomon : > On Aug 24, 2011, at 12:09 AM, Janek Warchoł wrote: > >> 2011/8/16 Han-Wen Nienhuys : >>> #2) sounds neat, but maybe Janek (who has spent some time messing >>> around with flags) wants to weigh in. >> >> As i've said in a private mail to Mike, i don't have anything against

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Aug 24, 2011, at 12:09 AM, Janek Warchoł wrote: > 2011/8/16 Han-Wen Nienhuys : >> #2) sounds neat, but maybe Janek (who has spent some time messing >> around with flags) wants to weigh in. > > As i've said in a private mail to Mike, i don't have anything against doing > so. > > Mike, i under

Re: Fixes heights and pure heights of stems. (issue 4898044)

2011/8/16 Han-Wen Nienhuys : > #2) sounds neat, but maybe Janek (who has spent some time messing > around with flags) wants to weigh in. As i've said in a private mail to Mike, i don't have anything against doing so. Mike, i understand that your patch changes some beams. I'd like to check what e

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Tue, Aug 16, 2011 at 4:38 AM, wrote: > 2)  Create a Flag grob (less trivial, I'd say two hours of work to > create the grob in define-grobs.scm, get it made in a new finalize > method for the stem engraver, copy and paste all of the flag stuff in > stem.cc into a new flag.cc, create an X-offse

Re: Fixes heights and pure heights of stems. (issue 4898044)

On 2011/08/15 21:33:07, Neil Puttock wrote: On 15 August 2011 13:31, wrote: That's every users who wants cross-staff stems for chords. Unless you can come up with a better interface for dealing with cross-staff stems, I'd rather you keep 'length for this case. I

Re: Fixes heights and pure heights of stems. (issue 4898044)

- Original Message - From: "Han-Wen Nienhuys" To: ; ; Sent: Monday, August 15, 2011 10:48 PM Subject: Re: Fixes heights and pure heights of stems. (issue 4898044) On Sun, Aug 14, 2011 at 1:25 PM, wrote: THE UGLY: Because this patch effects stem extents across the

Re: Fixes heights and pure heights of stems. (issue 4898044)

I see what you mean about flags, and I think there are two ways to go with it. 1) Reinstate stem-begin-position and stem-end-position in this patch (trivial: would take 10 minutes). 2) Create a Flag grob (less trivial, I'd say two hours of work to create the grob in define-grobs.scm, get it ma

Re: Fixes heights and pure heights of stems. (issue 4898044)

overall comment: since you're hijacking the Y-extent property for storing the logical end of the stem, how will you deal with stem flags that are oddly shaped? I think it is legit for a flag to be larger than the end point of the stem. consider a hypothetical flag / |/ x| (hope you get th

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Aug 15, 2011, at 11:33 PM, Neil Puttock wrote: > On 15 August 2011 13:31, wrote: > >> Also, just a quick reply to let you know that the calc_stem_end and >> calc_stem_begin methods are left in the code base for people who want to >> override the Y-extent of the stem while conserving either

Re: Fixes heights and pure heights of stems. (issue 4898044)

On Sun, Aug 14, 2011 at 1:25 PM, wrote: > THE UGLY: > > Because this patch effects stem extents across the board, the regtest > comparisons are nightmarish to check.  The layout probably does not > change at all in most regtests (at least not to the naked eye), but > because of the change in Y-e

Re: Fixes heights and pure heights of stems. (issue 4898044)

On 15 August 2011 13:31, wrote: > Also, just a quick reply to let you know that the calc_stem_end and > calc_stem_begin methods are left in the code base for people who want to > override the Y-extent of the stem while conserving either the beginning > or end of the stem, ie: > > \override Stem

Re: Fixes heights and pure heights of stems. (issue 4898044)

Hey all, I've addressed all the concerns sent in so far in a new patch set. Cheers, MS http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixes heights and pure heights of stems. (issue 4898044)

Hey all, Thanks for your comments! I'm outta town now, so I won't be able to fully reply till tomorrow, but I'm working on everything you've suggested with the code and regtests. Also, just a quick reply to let you know that the calc_stem_end and calc_stem_begin methods are left in the code bas

Re: Fixes heights and pure heights of stems. (issue 4898044)

Hi Mike, This looks like a work in progress. What's going on with the begin/end position methods? You've removed the grob properties, but kept the exported callbacks plus an entry in pure-conversions-alist which does nothing. Cheers, Neil http://codereview.appspot.com/4898044/diff/1/scm/flag

Re: Fixes heights and pure heights of stems. (issue 4898044)

Wow, this is a major rewrite! I can't comment on the logic, and at present I can't test it, so I've just made a few nit-picking comments on style. Trevor http://codereview.appspot.com/4898044/diff/1/input/regression/stem-length-estimation.ly File input/regression/stem-length-estimation.ly (rig

Re: Fixes heights and pure heights of stems. (issue 4898044)

Same remark for fingerings. See input/regression/fingering-cross-staff.ly Consecutive ties look better in input/regression/tie-single.ly http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.or

Re: Fixes heights and pure heights of stems. (issue 4898044)

Benchmark done on a book with many beams: without the patch: 51.8s and 80 pages with the patch: 52.2s and 83 pages I also noticed some ugliness's between beams and figured bass. The figures stay exactly where they were, but the stems are longer and collide a bit with them. Bertrand http://coder

Fixes heights and pure heights of stems. (issue 4898044)

Reviewers: , Message: Hey all, This patch fixes a bug in LilyPond that has nagged me for some time: incorrect heights and pure heights for stems. THE GOOD: With this patch, heights for stems are correct (they weren't before) and pure heights are better approximations. There is one new regtest