Re: Auto-beaming infrastructure redo

[Carl Sorensen]

On 7/2/10 9:25 AM, "Graham Percival" <address@hidden> wrote:

> On Fri, Jul 02, 2010 at 08:22:15AM -0600, Carl Sorensen wrote:
>> I'm trying to redo auto-beaming so that it matches better with what I read
>> in the literature.  When I get it done, I hope to have it set up so that the
>> default properties do the right thing, and all we have to do is define
>> exceptions.  Working in this framework, I think the LilyPond syntax needs to
>> change.
> 
> The 2.14 release just got pushed back 1-2 months.

Perhaps.  I think it's more like 1-2 weeks.  And it might be no time at all.
There are *still* critical bugs hanging out there.
> 
> I'm not disputing the musical need for this additional reworking,
> nor your technical expertise in this area.  Your email was very
> well-reasoned and convincing.
> 
> But I'm disappointed that no user (should have) ever tried out
> your previous work (since it never reached a stable or beta
> version), and frustrated at our continual
> project-starting-with-no-finishing.

Trevor and Neil tested out the previous work pretty thoroughly.  And their
comments led to me spending a couple of weeks reviewing the engraving
literature (Ross, Stone, and Read), trying to make sure that I was't just
recoding existing functionality, but trying to get the functionality
*right*.

I'm ready to finish.  I could release a patch today.  This is *not* a
do-over, it's a response to the comments on my previous patch.  As I was
preparing the new patch (with the concepts of subdivideUnit, beatLengths,
and beatCombinations in it), I realized that I hadn't put any of these
issues past the community, and there might be reasonable objections to them.
I could try to slip them by just as part of the patch, but I thought it
better to get the discussions out in the open, since it would make a
fundamental change.

The biggest issues in the current patch are moving from the beamSettings
property that contains information for all time signatures (as implemented
last December) to a time-signature-settings property that contains property
values for given time signatures, and the values are read then stored in
context properties when the time signature changes.  Getting that right took
a lot more thinking and coding time than I expected it to.  But it's right
now.  And it won't require major changes when we get the right set of
context properties figured out.

The current discussion basically centers on *which* context properties
should be used to control autobeaming and hence should be stored in
time-signature-settings.  This will happen quite quickly once a decision is
reached.

If you'd prefer, I can just go ahead and post a patch for comments.

Thanks,

Carl