Re: PATCH: Issue 638 Autobeaming

2009-12-19 Thread Carl Sorensen
On 12/18/09 10:57 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/18/09 9:52 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl, you wrote Friday, December 18, 2009 4:21 PM On 12/18/09 2:49 AM, Trevor Daniels t.dani...@treda.co.uk wrote:

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Trevor Daniels
devel lilypond-devel@gnu.org Sent: Thursday, December 17, 2009 8:29 PM Subject: Re: PATCH: Issue 638 Autobeaming On 12/17/09 11:39 AM, Carl Sorensen c_soren...@byu.edu wrote: That bug has now been fixed, and your example now beams the whole measure (as expected). Patch update soon to arrive

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Trevor Daniels
...@byu.edu To: David Kastrup d...@gnu.org Cc: Lily devel lilypond-devel@gnu.org Sent: Thursday, December 17, 2009 8:29 PM Subject: Re: PATCH: Issue 638 Autobeaming On 12/17/09 11:39 AM, Carl Sorensen c_soren...@byu.edu wrote: That bug has now been fixed, and your example now beams the whole

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread David Kastrup
Trevor Daniels t.dani...@treda.co.uk writes: Carl, A question. Does your code require autobeaming rules to be defined for beams of every possible duration? I ask because the following example beams inconsistently, and I'm not sure if this is due to your code or differences in the

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Carl Sorensen
On 12/18/09 3:58 AM, David Kastrup d...@gnu.org wrote: Trevor Daniels t.dani...@treda.co.uk writes: Carl, A question. Does your code require autobeaming rules to be defined for beams of every possible duration? I ask because the following example beams inconsistently, and I'm not

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Carl Sorensen
On 12/18/09 2:49 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl, A question. Does your code require autobeaming rules to be defined for beams of every possible duration? I ask because the following example beams inconsistently, and I'm not sure if this is due to your code or

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Trevor Daniels
Carl, you wrote Friday, December 18, 2009 4:21 PM On 12/18/09 2:49 AM, Trevor Daniels t.dani...@treda.co.uk wrote: A question. Does your code require autobeaming rules to be defined for beams of every possible duration? I ask because the following example beams inconsistently, and I'm not

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Carl Sorensen
On 12/18/09 9:52 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl, you wrote Friday, December 18, 2009 4:21 PM On 12/18/09 2:49 AM, Trevor Daniels t.dani...@treda.co.uk wrote: A question. Does your code require autobeaming rules to be defined for beams of every possible

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread David Kastrup
Carl Sorensen c_soren...@byu.edu writes: On 12/18/09 3:58 AM, David Kastrup d...@gnu.org wrote: I think that if we establish the rule a broken beam decision is never reconsidered we can abolish the '* rule for beaming patterns and instead let a non-specified minimal duration always be broken

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread Carl Sorensen
On 12/18/09 10:13 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/18/09 3:58 AM, David Kastrup d...@gnu.org wrote: I think that if we establish the rule a broken beam decision is never reconsidered we can abolish the '* rule for beaming patterns

Re: PATCH: Issue 638 Autobeaming

2009-12-18 Thread David Kastrup
Carl Sorensen c_soren...@byu.edu writes: On 12/18/09 9:52 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl, you wrote Friday, December 18, 2009 4:21 PM On 12/18/09 2:49 AM, Trevor Daniels t.dani...@treda.co.uk wrote: A question. Does your code require autobeaming rules to be

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread David Kastrup
Carl Sorensen c_soren...@byu.edu writes: On 12/16/09 10:23 PM, Frédéric Bron frederic.b...@m4x.org wrote: At last, thanks to help above and beyond the call of duty by Neil, I have finally got the autobeam engraver fixed so it beams 4 4 right when there are 16th notes in the 2nd or 4th beat

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread Carl Sorensen
On 12/17/09 1:25 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/16/09 10:23 PM, Frédéric Bron frederic.b...@m4x.org wrote: At last, thanks to help above and beyond the call of duty by Neil, I have finally got the autobeam engraver fixed so it beams

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread Carl Sorensen
On 12/17/09 1:25 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/16/09 10:23 PM, Frédéric Bron frederic.b...@m4x.org wrote: Deep breath. So it would appear that no terminal/irreversible decision based on the minimum duration has been done yet

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread David Kastrup
Carl Sorensen c_soren...@byu.edu writes: On 12/17/09 1:25 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/16/09 10:23 PM, Frédéric Bron frederic.b...@m4x.org wrote: Deep breath. So it would appear that no terminal/irreversible decision based on

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread Carl Sorensen
On 12/17/09 7:54 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/17/09 1:25 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: On 12/16/09 10:23 PM, Frédéric Bron frederic.b...@m4x.org wrote: Deep breath. So it

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread David Kastrup
Carl Sorensen c_soren...@byu.edu writes: With the revised code and adding an autobeaming rule for 1/64 notes to the default beam settings, the beaming is consistent. Without the addition of an autobeaming rule for 1/64 notes the beaming appears to be inconsistent. I will investigate this

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread Carl Sorensen
On 12/17/09 9:53 AM, David Kastrup d...@gnu.org wrote: Carl Sorensen c_soren...@byu.edu writes: With the revised code and adding an autobeaming rule for 1/64 notes to the default beam settings, the beaming is consistent. Without the addition of an autobeaming rule for 1/64 notes the

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread Carl Sorensen
On 12/17/09 11:39 AM, Carl Sorensen c_soren...@byu.edu wrote: That bug has now been fixed, and your example now beams the whole measure (as expected). Patch update soon to arrive. Patch set 2 is now on Rietveld. http://codereview.appspot.com/179083 Thanks, Carl

Re: PATCH: Issue 638 Autobeaming

2009-12-17 Thread David Kastrup
Carl Sorensen c_soren...@byu.edu writes: On 12/17/09 9:53 AM, David Kastrup d...@gnu.org wrote: Of course, the results were quite different from what I half expected to see. Yes. That difference is due to a pre-existing bug in the code. The consider_end check used the current duration,

Re: PATCH: Issue 638 Autobeaming

2009-12-16 Thread Andrew Hawryluk
On Wed, Dec 16, 2009 at 1:20 PM, Carl Sorensen c_soren...@byu.edu wrote: At last, thanks to help above and beyond the call of duty by Neil, I have finally got the autobeam engraver fixed so it beams 4 4 right when there are 16th notes in the 2nd or 4th beat of the measure. Bravo, Carl! I can't

Re: PATCH: Issue 638 Autobeaming

2009-12-16 Thread Frédéric Bron
At last, thanks to help above and beyond the call of duty by Neil, I have finally got the autobeam engraver fixed so it beams 4 4 right when there are 16th notes in the 2nd or 4th beat of the measure. Very nice job. That's now a good reason for me to upgrade to 2.13.X. Does this apply only to

Re: PATCH: Issue 638 Autobeaming

2009-12-16 Thread Carl Sorensen
On 12/16/09 10:23 PM, Frédéric Bron frederic.b...@m4x.org wrote: At last, thanks to help above and beyond the call of duty by Neil, I have finally got the autobeam engraver fixed so it beams 4 4 right when there are 16th notes in the 2nd or 4th beat of the measure. Very nice job. That's