lilypond-devel
[Top][All Lists]
Advanced

[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 17:53:06 -0600



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

> 2009/4/14 Carl D. Sorensen <address@hidden>:
> 
>> It seems to me to be the same to set an alist for AutoBeamSetting.  When
>> it's time to do the auto-beam calculations, the code can ask the context for
>> the property setting.
> 
> Fine, but you can't make it appear to be a grob; it must be
> autoBeamSetting as a context property, which limits its syntax to `set
> [Context].autoBeamSetting = setting', unless you're proposing to
> resurrect the old style overrides for autobeaming which were removed
> some time around version 2.0.0:
> 
> \property Voice.autoBeamSettings \override #'(BE P Q N M) = dur
> 
> Which code in lily-guile.cc allows the usage you propose?  There's
> some blurb in the file related to autobeaming, but I think that's
> merely left over from the old-style autoBeamSettings code.

I think you're right.  I reviewed the parser again, and I think my initial
impression is wrong.

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.

Of course, my knowledge of the internal details is still somewhat shadowy...


Thanks for putting up with my questions that push the boundaries...

Carl





reply via email to

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