Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/13/09 2:44 AM, "Trevor Daniels" <address@hidden> wrote:

> 
> 
> Carl D. Sorensen wrote Monday, April 13, 2009 1:32 AM
> 
>> On 4/12/09 6:14 AM, "Trevor Daniels" <address@hidden>
>> wrote:
>> 
>>> I'm a bit concerned about dropping the easy
>>> beatLength/beatGrouping
>>> interface, which seems to be prefered by most users, and
>>> replacing
>>> it with a more complex one, but I don't have any suggestions
>>> (which
>>> work) to make at present.  Might a special user interface be
>>> preferable to \override and \revert?
>> 
>> Instead of
>> 
>> \set beatGrouping = #'(1 3 3)
>> 
>> (which can be wrong, because it doesn't reference the time
>> signature), it
>> would be something like
>> 
>> \override #'autoBeamSetting #'(end 7 8) =
>>  \makeAutoBeamSetting '(* . ((1 . 8) (4 . 8) (7 . 8)))
> 
> Should this not be \set rather than \override, as
> this is a context property?
> 

According to LM 5.3.5, autoBeamSetting would not be a context property,
because it doesn't change over time.  (I think the definition of context
property and grob property here is a bit confusing, and perhaps wrong).

Also, according to LM 5.3.5, the main difference between \set and \override
is that \override *adds* a new value to the front of the alist, while \set
*replaces* the value with the one being set.  Therefore, an \override can be
\reverted, but a \set cannot.  To me, changes to properties that affect the
layout of music should always be revertable.  That's why I chose \override
rather than \set.

>> I agree this is a bit more difficult to type, and may be more
>> difficult to
>> understand.  But I think the advantages of
>> 
>> A) Having the time signature explicitly included
>> make this worthwhile.
> 
> Absolutely
> 
>> B) Being explicit about the grouping points
>> make this worthwhile.
> 
> Not so sure about this.
> 
>  \set #'autoBeamSetting #'(end 7 8) =
>   \makeAutoBeamSetting '(* . ((1 . 8) (4 . 8) (7 . 8)))
> 
> could be written equivalently as
> 
>  \set #'autoBeamSetting #'(lengths 7 8) =
>   \makeAutoBeamSetting '(* . ( 1 3 3 ))

I originally thought about this syntax, but elected not to use it because it
would be difficult to capture the default behavior of 2 2, which is to break
beams at the 1/4 note positions.

\override #'autoBeamSetting #'(end 2 2) =
  \makeAutoBeamSetting '(* . ((1 . 4) (2 . 4) (3 . 4) (4 . 4))

I suppose it would be possible to write

\override #'autoBeamSetting #'(end 2 2) =
  \makeAutoBeamSetting '(* . ( 0.5 0.5 0.5 0.5))

using the grouping notation.

I don't think I'd want to use 'lengths as the symbol regardless.  The symbol
'end is not used to show that the timing of the rule is specified in ending
moments. Rather, it's used to show that this a rule for ending beams, as
opposed to subdividing them.

> 
> where the beat length is either dem if * or beam
> duration if specified.  makeAutoBeamSetting could
> convert these to the equivalent 'end' form.
> 
> Granted you could not write
> 
>  \set #'autoBeamSetting #'(end 7 8) =
>   \makeAutoBeamSetting '(* . ((3 . 16) (4 . 8) (7 . 8)))
> 
> in the alternative syntax, so some flexibility would
> be lost, but as this would affect only 16th and shorter
> beams this would work:
> 
>  \set #'autoBeamSetting #'(lengths 7 8) =
>   \makeAutoBeamSetting '(* . ( 4 3 )
>                     16 . ( 3 5 6 ))

You're missing paragraphs on this setting.  It should rather be written as

\makeAutoBeamSetting '((* . (4 3))
                       (16 . (3 5 6)))

which means I've been missing a set of paragraphs in my examples too.

The problem with this setting is that if you want to have the rule apply to
32nd beams you need to explicitly include them:
 
\makeAutoBeamSetting '((* . (4 3))
                       (16 . (3 5 6))
                       (32 . (6 10 12))
> 
> Hhm.  Now I'm not sure which I prefer.  This example
> looks worse!  And the grouping form can be specified
> in an invalid way, meaning errors can be generated.
> One advantage of the ending form is that pretty well
> everything you can write is valid, as the final beam
> will always end at the end of the bar even if this is
> not specified.  Only specifying moments beyond the end
> of the bar would be erroneous.
> 
> Perhaps on balance I prefer specifying end points
> after all.

I think the real problem is deciding whether or not we need both numerator
and denominator in the moments.

For example, we could specify ending numerators (instead of groups) in the
setting above:

\makeAutoBeamSetting '((* . (4 3))
                       (16 . (3 8 14))
                       (32 . (6 16 28))

This works fine for everything but the * rule, which has no denominator
listed.

Ahh -- I just thought that 8th notes are the longest notes with beams.  So
we could specify the *  entries as eighths, and allow fractions

\makeAutoBeamSetting '((* . (1.5 4 7))

would then work properly.  Eighth beams would end at 4/8 and 7/8; 16th and
shorter would end at 3/16, 4/8, and 7/8.  And we could avoid the whole cons
cell entry, which I find rather difficult.

I think I actually like this syntax quite well.  Let the code take care of
all the complexity, and let users have it easy.

Thanks,

Carl