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" <c_soren...@byu.edu>
To: "lilypond-devel" <lilypond-devel@gnu.org>
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
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel