Re: Autobeaming

[Carl Sorensen]

On 12/29/09 2:14 PM, "Joe Neeman" <address@hidden> wrote:

> On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote:
>> 
>> 
>> On 12/29/09 8:41 AM, "Carl Sorensen" <address@hidden> wrote:
>> 
>>> 
>>> 
>>> 
>>> 
>>> On 12/29/09 4:48 AM, "Trevor Daniels" <address@hidden> wrote:
>>> 
>>>> Hi Carl
>>>> 
>>>> This looks like a much better approach.  It means the
>>>> special \overrideTimeSignatureSettings will be required
>>>> only rarely, and setting autoBeamRules for just the
>>>> current time signature should have a much simpler
>>>> format as the time signature is known - is that right?
>>> 
>>> Sort of.
>>> 
>>> I wouldn't recommend setting autoBeamRules for the current time signature,
>>> because that setting will disappear if the time signature changes.
>>> 
>>> I think that proper way to get new autoBeamRules is to override the
>>> timeSignatureSettings.
>>> 
>>> But if one wants to avoid that complication, one can just set autoBeamRules
>>> for the current time signature.
>>> 
>> 
>> I think I've got a consistent idea now.  I think I can add a property
>> (probably 'details to avoid namespace pollution, but maybe
>> timeSignatureDefaults) to the TimeSignature grob.
> 
> I much prefer leaving it as a context property. Grob properties of the
> TimeSignature grob should be things that affect the appearance of the
> TimeSignature grob, not the creation of beams.
> 
> If you were to use a context property, why would you need the special
> command \overrideTimeSignatureSettings to change it? That is, why
> couldn't people just use \set? If it helps, we could extend \set to
> allow nested properties (the same thing that
> http://codereview.appspot.com/182042/show does for paper-block
> variables).

Because I want to be able to \revert, not just \unset.  I want to be able to
change to some custom behavior, then go back to the default behavior without
having to know what the default behavior is in detail.

IIUC, \override is roughly equivalent to \set value (cons new-value
old-value).  I want to have that functionality, so that old-value is still
available for a \revert.

 But certainly nested properties would help in making this change.

Why have we decided that context properties can only be \set, and grob
properties can only be \overridden?  In version 2.0 we had two kinds of
properties, layout properties and translation properties.  I think that
translation properties in those days are what we now call context
properties, and that what were then called layout properties are now called
grob properties.  Also, in version 2.0 we could either \set (destructively
assign a value) or \override (push a value on the stack).  In fact,
according to the documentation, \override and \revert were the equivalent of
push and pop.

Now I think we have different behavior: context properties get \set and
\unset; grob properties get \override and \revert.  And IIUC, \override
pushes a value on the stack, but \revert doesn't pull a value, instead it
goes back to the default value.  That is, if I do

\override Context.Grob #'my-prop = #'13
\override Context.Grob #'my-prop = #'15
\revert   Context.Grob #'my-prop

the value of #'my-prop will not be 13; instead it will be the value it had
before the first \override.

I'm actually fine with this behavior; that way both \revert and \override
are consistent, regardless of where they come in the file.  \override sets
a new value, and \revert puts me back to the default value.

But for some reason unknown to me, when LilyPond 2.1.22 was released, (see
http://thread.gmane.org/gmane.comp.gnu.lilypond.announce/143), the syntax
changed.

According to what I can read, the syntax changed for two reasons.  First, it
was an attempt to delineate between translator (context) properties, and
layout (grob) properties.  Second, it was to reduce some shift/reduce
conflicts in the parser.

I would actually prefer the terminology of translation and layout
properties, where translation affects the conversion of music expressions to
grobs, and layout affects the appearance of grobs.  This seems to me to be
more logically consistent, and helps me understand the difference between
the two types of properties.

But I wish that both types of properties had \override and \revert
functionality.  In 2.0 they did; in 2.1.22 the \set functionality was
eliminated from layout properties and the \override functionality was
eliminated from translator properties.

When we don't have nested context properties, \override is probably not very
important.  But if we do, I think that \override functionality (regardless
of what it's called) is quite important.

If we could allow nested context properties, and get \set to do the
equivalent of \override, and \unset do the equivalent of \revert, then I'd
be all set to do TimeSignatureDefinitions as a context property.

Thanks,

Carl




Thanks,

Carl