[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reverting Beat Grouping Commands

From: Carl D. Sorensen
Subject: Re: Reverting Beat Grouping Commands
Date: Tue, 14 Apr 2009 15:21:15 -0600

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/ 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]