Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/21/09 3:04 PM, "Neil Puttock" <address@hidden> wrote:

> 2009/4/21 Carl D. Sorensen <address@hidden>:
> 
>> I haven't checked yet for beam subdividing (I will need to, I know), but for
>> autobeaming, the work is done in a scheme callback, where the context is
>> available.
> 
> There is no callback, otherwise get_property ("autoBeamCheck") would
> automatically return #t or #f; it has to be evaluated, as I mentioned
> above, using an explicit procedure call.
> 
>> Already the autobeam rules are called as context properties.  It
>> will be no problem to get them from a context description property in the
>> autobeam callback.
> 
> I'm not sure what you have in mind with a `context description
> property'.  As it stands, we have a set of context properties, one of
> which is used to call a procedure (autoBeamCheck); inside the
> procedure other context properties (including autoBeamSettings) are
> read.

I don't have the right terminology to explain my thinking, so I've hacked
together a quick proof-of-concept of my idea.


I'm attaching a patch that implements a pseudo-grob that allows me to A)
store the auto-beam-settings alist, and B) change the value for an
individual time signature using \override.

I'm also attaching a lilypond file that demonstrates how the behavior will
work.

NOTE:  I have not actually implemented the new auto-beam-settings for the
beaming; I've just demonstrated that I can get a nice alist of the settings
to use in auto-beam.scm.   The alist will be printed at the console.

Does this help clarify what I'm thinking?

Thanks,

Carl

0001-Test-of-AutoBeamPlaceholder-to-allow-override-of-au.patch
Description: 0001-Test-of-AutoBeamPlaceholder-to-allow-override-of-au.patch

test-auto-beam-settings.ly
Description: test-auto-beam-settings.ly