Re: Autobeaming

[Trevor Daniels]

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?

Trevor

----- Original Message ----- 
From: "Carl Sorensen" <address@hidden>
To: "lilypond-devel" <address@hidden>
Sent: Tuesday, December 29, 2009 2:11 AM
Subject: Autobeaming


I've been continuing to work on the logical structure of autobeaming 
rules,
because the rules aren't right yet.  There are still some rules that 
don't
make sense, and in trying to make things make sense, I've run into 
some
philosophical issues.

I'm starting to believe that there should be a context property
timeSignatureSettings that contains the settings that should go with 
a time
signature.  These settings should include beatLength, 
measureGrouping, and
beaming rules (right now, just end rules, but eventually subdivide 
and
potentially begin).

This property stores default values for beatLength, measureGrouping, 
and
autoBeamRules.  Then, when the time signature is changed, the 
context
properties of beatLength, measureGrouping, and autoBeamRules are set 
to the
values from the timeSignatureSettings.

Then, if desired, the user can change the values of beatLength,
measureGrouping, or autoBeamRules, they can do so directly by means 
of
the \set command.

If a user wants to change the timeSignatureSettings values for 
beatLength,
measureGrouping, or autoBeamRules, they can do so with an
\overrideTimeSignatureSettings or \revertTimeSignatureSettings 
command.
Having done so, a simple change of time signature will implement the 
new
time signature settings.

Does this seem like a feasible architecture?

Thanks,

Carl







_______________________________________________
lilypond-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/lilypond-devel