Re: Autobeaming

[Carl Sorensen]

On 12/31/09 12:44 PM, "Han-Wen Nienhuys" <address@hidden> wrote:

> On Thu, Dec 31, 2009 at 2:33 PM, Carl Sorensen <address@hidden> wrote:
>>>> 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.
> 
> if you do
> 
>   \override Stem  #'direction = #1
> 
> we actually check the type associated with #'direction for grobs, so
> we can warn when people do
> 
>   \override Stem  #'direction = #'blah
> 
> or
> 
>   \override Stem  #21 = #1
> 
> the code has (or had) some contortions to switch this off for the auto
> beam property case.

Oh, yes.  There may still be a comment about it, but the hack has been
removed.  Instead, we're using special beam-setting code, and we don't do
\revert and \override.  We use a music function (as you suggested we
should).  And since it's part of a special case anyway, then using special
beam-setting code doesn't seem to me to be a problem.

> 
> 
>>>  \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.
> 
> The argument could be a symbol though,
> 
>   #(set-auto-beaming 'timesig-3-4)
> 
> so the beaming can still be set per voice.  Hmm... not sure.
> 
>> And IIUC, the time signature properties are part of the Timing context, not
>> a Voice context.
> 
> yes, I left out the context out of laziness.
> 
>>> 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.
> 
> No that sounds fine, but the time signature settings themselves (ie.
> whether 6/8 = 3+3 or 2+2+2) should not be part of the context
> properties.

But each staff can have a separate time signature by moving the
Timing_egraver to the staff context, and we show examples of that, so to
make that work, the time signature settings need to be part of a context
propery, I think.  Is there something wrong with having them do that?

Thanks,

Carl