On 12/31/09 12:44 PM, "Han-Wen Nienhuys" <hanw...@gmail.com> wrote:
> On Thu, Dec 31, 2009 at 2:33 PM, Carl Sorensen <c_soren...@byu.edu> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
