Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/18/09 5:54 PM, "Neil Puttock" <address@hidden> wrote:

> 2009/4/15 Carl D. Sorensen <address@hidden>:
> 
>> So why can't we define an AutoBeamPlaceHolder grob description (defined in
>> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
>> scm/define-grob-interfaces.scm)?  It would have no engraver, but I can't see
>> that having an engraver is necessary for having a grob description.  And, at
>> least as far as I can determine, the things that are altered by \override
>> are special context properties called "element descriptions".  I'm not aware
>> of any requirement that all descriptions have to have engravers.
> 
> How will the engraver access the properties from this grob
> description?  AFAIK, the overloaded methods get_property () and
> set_property () must have a pointer to a grob which has been created
> in an engraver, whereas the context property versions can be called
> implicitly (but then they are more limited when it comes to evaluation
> since you have to use an explicit scm_call_* for procedures).

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.  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.



Carl