Re: Autobeaming

[Han-Wen Nienhuys]

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.


>>  \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.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen