[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Carl Sorensen
Subject: Autobeaming
Date: Mon, 28 Dec 2009 19:11:52 -0700

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]