Re: Reverting Beat Grouping Commands

[Trevor Daniels]

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".

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.

> Would you like me to (a) write this, or (b) give a bit more 
> fleshed-out
> outline of it?

No thanks, I'm pretty sure I can write it.  But I wonder
if this is really the best approach.

> > We would need
> > to add a couple of lines to default-auto-beam-check in 
> > auto-beam.scm
> > like this:
> >
> > change
> >
> > (settings (get 'autoBeamSettings '()))
> >
> > to
> >
> > (settings (if (get 'useBeamEndingRules #t)
> >   (get 'autoBeamSettings '())
> >   '()))
> >
> > What do you think?  It seems to work fine.  Shall I make this my
> > first frog task?
>
> 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.

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

Trevor