lilypond-devel
[Top][All Lists]
Advanced

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

Re: Reverting Beat Grouping Commands


From: Carl D. Sorensen
Subject: Re: Reverting Beat Grouping Commands
Date: Tue, 14 Apr 2009 12:37:33 -0600



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

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.

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.

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

>>> \override #'autoBeamSetting #'(end 2 2) =
>>>  \makeAutoBeamSetting '(* . ((1 . 4) (2 . 4) (3 . 4) (4 . 4))
>> 
>> I didn't think of this particular example, but came
>> to the same conclusion.
>> 
>>>> 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.

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.

Thanks,

Carl





reply via email to

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