On Tue, 2009-12-29 at 11:27 -0700, Carl Sorensen wrote: > > > On 12/29/09 8:41 AM, "Carl Sorensen" <c_soren...@byu.edu> wrote: > > > > > > > > > > > On 12/29/09 4:48 AM, "Trevor Daniels" <t.dani...@treda.co.uk> 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). Joe _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel