Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/5/09 9:02 AM, "Trevor Daniels" <address@hidden> wrote:

> 
> 
> Carl D. Sorensen wrote Sunday, April 05, 2009 3:16 PM
> 
>> On 4/5/09 5:05 AM, "Trevor Daniels" <address@hidden> wrote:
>> 
>>> Carl
>>> 
>>> As an alternative to having a complex time-signature-dependent
>>> revert command why don't we introduce a context property to
>>> control
>>> whether the beam-ending rules should be applied or not?  This
>>> seems
>>> particularly easy to do, and is conceptually simple.
>> 
>> This would be easy to do, and might meet some of the needs.  But
>> if people
>> want to use complex beam-ending rules rather than beat-grouping,
>> they'll
>> still need to revert the predefined rules, won't they?  So
>> wouldn't the
>> revert function still be useful?
> 
> My objective is to make it as simple as possible for people
> to use beat-grouping.  At the moment they have to understand
> how to turn off the beam-ending rules with revert first, and
> they would still need to understand this even with a revert-all
> function.  What I'm proposing is a simpler way for those who
> don't what to get into the beam-ending rules - we simply say
> "to use beat grouping, \set useBeamEndingRules to ##f".

beatGrouping and auto-beam-ending-rules are not currently mutually
exclusive.  Do we want to make them mutually exclusive?  I honestly don't
know the answer to this question.  I added beatGrouping to the auto-beam
code because the lack of it was a known issue.  I don't know what the
"right" thing to do is.

Currently, in scm/auto-beam.scm, the default auto-beam-settings make use
of beatLength, beatGrouping, and explicit settings.  If they are cleanly
separated, I think we'll need to adjust that significantly.

One advantage to your proposal is that we wouldn't have to eliminate the
default auto-beam settings.  The revert-all-auto-beam-settings would
eliminate the rules from the list, and there's no way to get them back.

Is it possible that one would want to use beatGrouping for one time
signature but use auto-beam-ending rules for another time signature?  Would
an entry ((end * * num den) . 'ignore)  be a useful way to ignore all
auto-beam ending rules that would be revertable?
 
> 
> Those writing their own beam-ending rules -have- to understand
> them, so they should have no difficulty using a revert.
> 
>> It seems like it shouldn't be so hard to write a function
>> (revert-all-auto-beam-settings numerator denominator) that would
>> get all the settings with that numerator and denominator, then one
>> by one
>> revert them.
> 
> No it's not hard to write, but the documention would be
> much simpler if we can clearly separate the two methods.

This is probably true.  But the code doesn't currently clearly separate the
two methods.  If we want to have the two methods be mutually exclusive, the
code should be changed.  It would actually greatly simplify the code to have
beatGrouping ignore the auto-beam settings.

What if we scrapped the current auto-beam code completely, and replaced it
with a structured beatGrouping, something like

((denominator (ending-beatGroupings) (subdivide-beatGroupings))
 (denominator2 (ending-beatGroupings) (subdivide-beatGroupings)))

We might then have something like the following in 6/8 time:

((8 (3 3) ())
 (16 (6 6) (6 6))
 (32 (4 4 4 4 4 4) (8 8 8)))

Then, if subdivideBeams  were set to #t, we could reduce the beam count for
a given level of beaming at the appropriate point.

I don't know if this is a better solution, but it might improve what
currently seems to me to be a very awkward system.

One weakness in this approach is that it provides no way to have an
auto-beam-ending rule for 3/32 beams (but I don't know of any 3/32 beams, so
I don't think that's a real limitation).

David Brobroff's request
<http://thread.gmane.org/gmane.comp.gnu.lilypond.general/46316/focus=46323>
could then be met by

((8 (4) ())
 (16 (4 4) ())
 (32 (8 8) (4 4 4 4)))

This would have the downside of requiring a complete redefinition every time
you changed the time signature, but it would get rid of the current problem
where you have to revert rules before you can add new ones.  It would also
put all automatic definitions of autobeam rules in one location in the
source tree, rather than having them spread across two files.

I don't know if this proposal has merit or not, but it seems like we really
ought to get to *some* combination of syntax and functionality that we think
really works.


> 
>> 
>> I don't see any problems in the function of the proposed code.
>> However, it
>> seems to introduce another property, which I think is unnecessary.
>> And I
>> think we want to avoid adding properties, unless it's necessary.
> 
> The consideration isn't a count of the number of properties
> but whether Lily becomes easier to use or not.  I think a \set
> command -is- easier to use, and the documentation would certainly
> be easier to write and understand if we can relegate all
> consideration of the beam-ending rules to just those who
> actually need their complexity.

Han-Wen has asked at times in the past that we watch out for name-space
pollution.  Granted, it was in the context of fret-diagrams, which have lots
of potential properties.  He's also expressed concern about unnecessary
syntactic sugar.  I could easily be overreacting in my concern about this.

I think that if we get a system that will do it *right*, all of both my
concerns and your concerns will go away.

Thanks for thinking about it!

> 
> That said, I'm happy to do either (or both) depending on your
> and others' views.

Great -- let's get a plan settled and move forward on it!

Thanks,

Carl