Re: Autobeaming

[Carl Sorensen]

On 12/31/09 8:56 AM, "Han-Wen Nienhuys" <address@hidden> wrote:

> On Thu, Dec 31, 2009 at 1:43 PM, Carl Sorensen <address@hidden> wrote:
> 
>>>>> 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.
>>> 
>>> This is a misconception, and the change in syntax was made to stop
>>> this misconception from breeding.   There never was a stack-like
>>> behavior for context/translation properties.   The suggested mechanism
>>> for this instead was to have the default be at a higher level context
>>> (eg. Score), and doing \unset at a lower level (eg. Staff) to restore
>>> the default.
>> 
>> OK.  When I was using 2.0 I didn't understand the internals well enough to
>> appreciate these nuances.  But when I read the docs yesterday, they implied
>> that /override and /revert applied to translation properties.
> 
> Well, the nuance is that \override do not strictly manipulate grob
> properties (ie. per grob settings), but the alist containing the
> defaults, and the alist is stored in a context property, so in a way
> it applies to a context property.
> 
> 
> 
>>>> \unset is actually important for internally-used context properties.  So
>>>> we would have to _add_ a revert function instead of just changing the
>>>> behaviour of \unset.
>>> 
>>> I think you are going at the problem from the wrong angle.  Are there
>>> other cases that need this new behavior?  (I suspect not).  If not,
>>> you should not implement something generic, but work on a more
>>> palatable syntax for what we currently have through music functions or
>>> some other existing extension mechanism.
>>> 
>> 
>> That's actually what the current mechanism is.  It uses a special music
>> function, and I can work within the current limitations.
>> 
>> However, David was objecting to the special case that timeSignatureSettings
>> would have as a revertable context property.  So I was trying to come up
>> with a method that would not use it as a special case.
> 
> Right - but it is worth noting that we removed the revertable property
> for the autobeam settings, exactly to not have the hack of doind
> \revert/\override on something that is not a grob.

I'm not sure exactly what you mean by this.

> 
> BTW, IIRC, we still have some special-case code for the hack to switch
> off type-checking on the nested properties for the beam settings.
> 
>> Your feedback (which I'm happy to accept) is to go ahead and use it as a
>> special case.  So I will.  And if we need to use it for another property in
>> the future, then I guess we can turn the special case into a general case.
>> 
>> Thanks for your feedback.  I'll proceed with the special case, and put some
>> comments in the code indicating why we do it.
> 
> Looking back through the thread, I am wondering why you do not expand
> these settings at the parsing stage, ie. have \time 2/4 expand to
> 
>  \set timeSigFraction = ..
>  \set measureGrouping = ..
>  #(set-auto-beaming .. )

Hmm -- I plan to do that.  But I need to have per-Voice beaming rules, so I
think the rules need to be a context property.

And IIUC, the time signature properties are part of the Timing context, not
a Voice context.

> 
> then you can be as flexible as you want.  Are these settings
> intrinsically part of the music or part of the translation process?

The time signature is part of the music.  The autobeaming is part of the
translation process, I think.

Do you think it's wrong to have the autobeam settings stored per context and
indexed by the time signature?  If that's a bad decision, I'd like to get
that straightened out before I finish implementing the code.

Thanks,

Carl