On 4/21/09 3:04 PM, "Neil Puttock" <n.putt...@gmail.com> wrote:
> 2009/4/21 Carl D. Sorensen <c_soren...@byu.edu>:
>
>> 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
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
