Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl D. Sorensen wrote Tuesday, April 14, 2009 7:37 PM

> On 4/14/09 1:39 AM, "Mats Bengtsson" <address@hidden> 
> wrote:
>
> > Have you forgot about the most basic difference between a context
> > property and a grob property?
> > All grob property are connected to a specific graphical object, 
> > so the
> > syntax is
> > \override Object #'propertyname = ...
> > In this case, there is no graphical object involved, right? 
> > Therefore,
> > it's naturally a context property, to be set using \set.
>
> If I read the code properly (I haven't yet implemented it, so I'm 
> not
> 100% positive), AutoBeamSetting could be the object, and 
> #'propertyname
> would be #'(end 4 4).  There is code in lily/lily-guile.cc that 
> allows this
> usage.

Using a pseudo-grob sounds a good approach.

> So I think that \override can still apply.  And I think it's the 
> right
> behavior.  Autobeaming can be complex.  A user ought to be able to 
> set new
> behavior and then revert to the original behavior.

Definitely an advantage.

> Trevor Daniels wrote:
> > It seems misleading, certainly.  Context properties can
> > change with time, but they don't have to and many do not.
> > The essential difference is that Context properties do not
> > have an associated grob.
>
> The "associated grob" means the property is inside an alist-chain, 
> as I read
> the code.  And, as mentioned above, in this case the actual 
> property that is
> being set (the auto-beam-settings for a particular time signature) 
> is buried
> in an alist, whose head is AutoBeamSettings.

Does this exist already?  If so, it is an undocumented
pseudo-grob.  Grouping the values as a list of lists and
turning them into a layout property is a brilliant idea!

> > > > 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.
> >
> > No, I think using decimal fractions is quite wrong,
> > and goes against everything else that Lily does with
> > moments.  You'll have problems with rounding, and in
> > compound times you'll need to specify thirds.
>
> Yes, but LilyPond has functions built in to handle the
> approximate decimal notation, and the \makeAutoBeamSetting
> could call that code to do the conversion to moments.

Still don't like it.  It would be a special case,
something else for people to get their heads round.
And there are people with really weird time signatures
based on large prime numbers - specifying beaming for
them with decimals would defeat any built-in rounding.

No, far better to stick to group lengths or moments.

> As an alternative, we could allow either integers or pairs as the
> grouping value, and if it's a pair treat it as a moment, if not 
> treat it as
> a numerator for the time signature denominator.  That's not hard 
> to code,
> but might be harder to explain in documentation.

Sounds fine to me.  In the documentation we explain
the easy one first, then say, "but if you need to do
this ..., you need a different format, like this ..."

Trevor