[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reverting Beat Grouping Commands

From: Trevor Daniels
Subject: Re: Reverting Beat Grouping Commands
Date: Tue, 14 Apr 2009 20:50:50 +0100

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/ that allows this

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]