Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

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?

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.

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

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

Thanks,

Carl