Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/14/09 2:19 PM, "Neil Puttock" <address@hidden> wrote:

> 2009/4/14 Carl D. Sorensen <address@hidden>:
>> 
>> 
>> 
>> On 4/14/09 1:39 AM, "Mats Bengtsson" <address@hidden> wrote:
>> 
>>> Have you forgot about the most basic difference between a context
>>> property and a grob property?
>>> All grob property are connected to a specific graphical object, so the
>>> syntax is
>>> \override Object #'propertyname = ...
>>> In this case, there is no graphical object involved, right? Therefore,
>>> it's naturally a context property, to be set using \set.
>>> 
>>>     /Mats
>> 
>> If I read the code properly (I haven't yet implemented it, so I'm not
>> 100% positive), AutoBeamSetting could be the object, and #'propertyname
>> would be #'(end 4 4).  There is code in lily/lily-guile.cc that allows this
>> usage.
> 
> I can't see how this would work at all, unless it remains a context property.

Yes, it would be a context property.

> 
> In order to be a grob (even an abstract one which doesn't itself
> represent graphical elements) AutoBeamSetting would have to be created
> by an engraver; how would that work, considering that the
> Auto_beam_engraver must know where to stop and start beams *before*
> the beaming grobs are created?  You 're effectively suggesting a grob
> which will rework spanner bounds after they've been created.  You can
> do this post-processing for things like noteheads and accidentals (in
> NoteCollision and AccidentalPlacement) , since all that happens is
> repositioning of fixed-width items (i.e. Item, not Spanner, grobs).
> 
> Property names can be nested, but you can't have what looks like an
> alist handle as a property.

Why not?

Carl