Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/5/1 Carl D. Sorensen :
>
>
>
> On 4/26/09 9:31 AM, "Neil Puttock"  wrote:
>
>> 2009/4/26 Trevor Daniels :
>>
>>> Just to recap, the advantage of \override over \set is that previously
>>> overridden values can be recovered by \revert because they are
>>> pushed onto a stack, whereas \unset simply restores the original
>>> default value.  Is that right?
>>
>> Yes.
>
> That's not the only advantage.  With /override, I can go down into the alist
> of properties and set an autobeam setting for just one time signature.  With
> /set, I need to set the whole alist.
>
> There are two reasons for this.  First, /set replaces the value, while
> /override conses the value to the front of the alist. Second, there's no way
> to get down into the alist with /set.
>
> I can do:
>  \override AutoBeamPlaceholder #'auto-beam-setting #'(end 3 4) =
>    #`((* . (,(ly:make-moment 1 4)
>            ,(ly:make-moment 2 4)
>            ,(ly:make-moment 3 4
>
> But I can't do:
>  \set myNewAutoBeamSetting #'(end 3 4) =
>    #`((* . (,(ly:make-moment 1 4)
>            ,(ly:make-moment 2 4)
>            ,(ly:make-moment 3 4
> because the = must come immediately after the myNewAutoBeamSetting.
>
>>
>> The problem with context properties is there's nowhere to store the
>> previous value, hence why the following doesn't work:
>>
>> \relative c' {
>>   \set fontSize = #-5
>>   c4
>>   \once \set fontSize = #4.7
>>   c4
>>   % reverts to default size, rather than -5
>>   c
>> }
>>
>>> If so, are there any other context
>>> properties that might benefit from a similar push-down stack?
>>
>> Definitely.
>>
>> There's an issue logged for this related to midi, but it would be
>> useful in many other situations.
>>
>>> My knowledge of the internals is not sufficient to judge whether this
>>> is feasible or even possible, but is this an alternative approach
>>> worth considering?
>>
>> I'm sure it's possible, but it's way beyond my capabilities.
>>
>
> As I've continued to hunt around the scm/define-grobs.scm, I notice that
> completize-grob-entry sets the 'is-grob? property of each grob to #t.  We
> could define entries in that list for which 'is-grob? would be set to #f.

If you did that, you wouldn't be able to use \override and \revert on
those entries:

#(set-object-property! 'Script 'is-grob? #f)

\relative c' {
  \override Script #'color = #red
  c4->
}

warning: not a grob name, `Script'

> We could also probably change the name from all-grob-descriptions to
> something like all-description-properties, and description properties would
> include grobs and other descriptions that need \override and \revert.
>
> Is this a potential way to move forward?

I'm not qualified to make that call, but my gut feeling is it's a dead end.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Neil Puttock wrote Sunday, April 26, 2009 4:31 PM



2009/4/26 Trevor Daniels :

Just to recap, the advantage of \override over \set is that 
previously

overridden values can be recovered by \revert because they are
pushed onto a stack, whereas \unset simply restores the original
default value. Is that right?


Yes.

The problem with context properties is there's nowhere to store 
the

previous value

My knowledge of the internals is not sufficient to judge whether 
this
is feasible or even possible, but is this [i.e. implementing a 
stack

fo context properties] an alternative approach
worth considering?


I'm sure it's possible, but it's way beyond my capabilities.


That means this is infeasible as a solution.

So we are left with two approaches:

a) Implement a pseudo-grob so we can use \override and \revert.

This would work, as Carl has demonstrated, but it muddies the
distinction between context and layout properties.

b) Implement special functions (as now) to change the auto-beaming
rules, so a pseudo-grob is not required

It would, in any case, be desirable to simplify the syntax of the 
user

interface, so some special functions at least will be provided.

For example, Graham suggested:


so what about
  \makeBeamGroupings #'(3 3 2)


and Carl replied:

So then we could have \makeBeamGroupings #'(3 3 2) translate into 
an
autoBeamSettings rule for the current time signature.  I like that 
idea a

lot!  Thanks!


So maybe we should implement all the user interface with special
functions along these lines, perhaps using

\makeAutoBeamRule  \revertAutoBeamRule

(I'd prefer push and pop rather than make and revert, but maybe
that's going too far)

and later

\makeAutoSubdivideRule  \revertAutoSubdivideRule

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/26 Trevor Daniels :

> Just to recap, the advantage of \override over \set is that previously
> overridden values can be recovered by \revert because they are
> pushed onto a stack, whereas \unset simply restores the original
> default value.  Is that right?

Yes.

The problem with context properties is there's nowhere to store the
previous value, hence why the following doesn't work:

\relative c' {
  \set fontSize = #-5
  c4
  \once \set fontSize = #4.7
  c4
  % reverts to default size, rather than -5
  c
}

> If so, are there any other context
> properties that might benefit from a similar push-down stack?

Definitely.

There's an issue logged for this related to midi, but it would be
useful in many other situations.

> My knowledge of the internals is not sufficient to judge whether this
> is feasible or even possible, but is this an alternative approach
> worth considering?

I'm sure it's possible, but it's way beyond my capabilities.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Neil Puttock wrote Saturday, April 25, 2009 4:27 PM



2009/4/25 Carl D. Sorensen :


On 4/25/09 8:24 AM, "Neil Puttock"  wrote:


2009/4/22 Carl D. Sorensen :


Does this help clarify what I'm thinking?


Yes, thank you.

To be honest, I'm not convinced by the idea of using a fake grob 
just

for the convenience of easy overriding and reverting.


Why would we not want to develop a mechanism that allows the use 
of standard

LilyPond syntax?


It's not standard syntax for context properties to pretend to be a
non-existent grob purely for the purposes of using \override and
\revert.


Just to recap, the advantage of \override over \set is that 
previously

overridden values can be recovered by \revert because they are
pushed onto a stack, whereas \unset simply restores the original
default value.  Is that right?  If so, are there any other context
properties that might benefit from a similar push-down stack?
The action of \set would need to be changed, and a new command,
\reset, maybe, created to pop the previous value, leaving \unset to
clear the stack to the default.  Then the autobeaming rules could
be implemented properly as context values.

My knowledge of the internals is not sufficient to judge whether 
this

is feasible or even possible, but is this an alternative approach
worth considering?

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

Resending including lily-devel.  Sorry, Neil, for the noise.


On 4/25/09 9:27 AM, "Neil Puttock"  wrote:

> 2009/4/25 Carl D. Sorensen :
>> 
>> 
>> 
>> On 4/25/09 8:24 AM, "Neil Puttock"  wrote:
>> 
>>> 2009/4/22 Carl D. Sorensen :
>>> 
 Does this help clarify what I'm thinking?
>>> 
>>> Yes, thank you.
>>> 
>>> To be honest, I'm not convinced by the idea of using a fake grob just
>>> for the convenience of easy overriding and reverting.
>> 
>> Why would we not want to develop a mechanism that allows the use of standard
>> LilyPond syntax?
> 
> It's not standard syntax for context properties to pretend to be a
> non-existent grob purely for the purposes of using \override and
> \revert.
> 
>> What are the disadvantages you see to this method?
> 
> None from a practical perspective.
> 
> I just think all-grob-descriptions should be reserved for real grobs.

OK, then, can we define a new context property called, e.g.
RevertibleContextProperties, and then call

\override RevertibleContextProperties #'auto-beam-settings #'(end 2 2) =
my-new-autobeam setting

Then, instead of defining a grob property, we could just, as part of
engraver-init.ly, set RevertibleContextProperties = '().

Does this seem better?

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/25 Carl D. Sorensen :
>
>
>
> On 4/25/09 8:24 AM, "Neil Puttock"  wrote:
>
>> 2009/4/22 Carl D. Sorensen :
>>
>>> Does this help clarify what I'm thinking?
>>
>> Yes, thank you.
>>
>> To be honest, I'm not convinced by the idea of using a fake grob just
>> for the convenience of easy overriding and reverting.
>
> Why would we not want to develop a mechanism that allows the use of standard
> LilyPond syntax?

It's not standard syntax for context properties to pretend to be a
non-existent grob purely for the purposes of using \override and
\revert.

> What are the disadvantages you see to this method?

None from a practical perspective.

I just think all-grob-descriptions should be reserved for real grobs.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/25/09 8:24 AM, "Neil Puttock"  wrote:

> 2009/4/22 Carl D. Sorensen :
> 
>> Does this help clarify what I'm thinking?
> 
> Yes, thank you.
> 
> To be honest, I'm not convinced by the idea of using a fake grob just
> for the convenience of easy overriding and reverting.

Why would we not want to develop a mechanism that allows the use of standard
LilyPond syntax?

What are the disadvantages you see to this method?

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/22 Carl D. Sorensen :

> Does this help clarify what I'm thinking?

Yes, thank you.

To be honest, I'm not convinced by the idea of using a fake grob just
for the convenience of easy overriding and reverting.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/21/09 3:04 PM, "Neil Puttock"  wrote:

> 2009/4/21 Carl D. Sorensen :
> 
>> I haven't checked yet for beam subdividing (I will need to, I know), but for
>> autobeaming, the work is done in a scheme callback, where the context is
>> available.
> 
> There is no callback, otherwise get_property ("autoBeamCheck") would
> automatically return #t or #f; it has to be evaluated, as I mentioned
> above, using an explicit procedure call.
> 
>> Already the autobeam rules are called as context properties.  It
>> will be no problem to get them from a context description property in the
>> autobeam callback.
> 
> I'm not sure what you have in mind with a `context description
> property'.  As it stands, we have a set of context properties, one of
> which is used to call a procedure (autoBeamCheck); inside the
> procedure other context properties (including autoBeamSettings) are
> read.

I don't have the right terminology to explain my thinking, so I've hacked
together a quick proof-of-concept of my idea.


I'm attaching a patch that implements a pseudo-grob that allows me to A)
store the auto-beam-settings alist, and B) change the value for an
individual time signature using \override.

I'm also attaching a lilypond file that demonstrates how the behavior will
work.

NOTE:  I have not actually implemented the new auto-beam-settings for the
beaming; I've just demonstrated that I can get a nice alist of the settings
to use in auto-beam.scm.   The alist will be printed at the console.

Does this help clarify what I'm thinking?

Thanks,

Carl




0001-Test-of-AutoBeamPlaceholder-to-allow-override-of-au.patch
Description:  0001-Test-of-AutoBeamPlaceholder-to-allow-override-of-au.patch


test-auto-beam-settings.ly
Description: test-auto-beam-settings.ly
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/21 Carl D. Sorensen :

> I haven't checked yet for beam subdividing (I will need to, I know), but for
> autobeaming, the work is done in a scheme callback, where the context is
> available.

There is no callback, otherwise get_property ("autoBeamCheck") would
automatically return #t or #f; it has to be evaluated, as I mentioned
above, using an explicit procedure call.

> Already the autobeam rules are called as context properties.  It
> will be no problem to get them from a context description property in the
> autobeam callback.

I'm not sure what you have in mind with a `context description
property'.  As it stands, we have a set of context properties, one of
which is used to call a procedure (autoBeamCheck); inside the
procedure other context properties (including autoBeamSettings) are
read.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/18/09 5:54 PM, "Neil Puttock"  wrote:

> 2009/4/15 Carl D. Sorensen :
> 
>> So why can't we define an AutoBeamPlaceHolder grob description (defined in
>> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
>> scm/define-grob-interfaces.scm)?  It would have no engraver, but I can't see
>> that having an engraver is necessary for having a grob description.  And, at
>> least as far as I can determine, the things that are altered by \override
>> are special context properties called "element descriptions".  I'm not aware
>> of any requirement that all descriptions have to have engravers.
> 
> How will the engraver access the properties from this grob
> description?  AFAIK, the overloaded methods get_property () and
> set_property () must have a pointer to a grob which has been created
> in an engraver, whereas the context property versions can be called
> implicitly (but then they are more limited when it comes to evaluation
> since you have to use an explicit scm_call_* for procedures).

I haven't checked yet for beam subdividing (I will need to, I know), but for
autobeaming, the work is done in a scheme callback, where the context is
available.  Already the autobeam rules are called as context properties.  It
will be no problem to get them from a context description property in the
autobeam callback.



Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/15 Carl D. Sorensen :

> So why can't we define an AutoBeamPlaceHolder grob description (defined in
> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
> scm/define-grob-interfaces.scm)?  It would have no engraver, but I can't see
> that having an engraver is necessary for having a grob description.  And, at
> least as far as I can determine, the things that are altered by \override
> are special context properties called "element descriptions".  I'm not aware
> of any requirement that all descriptions have to have engravers.

How will the engraver access the properties from this grob
description?  AFAIK, the overloaded methods get_property () and
set_property () must have a pointer to a grob which has been created
in an engraver, whereas the context property versions can be called
implicitly (but then they are more limited when it comes to evaluation
since you have to use an explicit scm_call_* for procedures).

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/14/09 4:20 PM, "Neil Puttock"  wrote:

> 2009/4/14 Carl D. Sorensen :
> 
>> It seems to me to be the same to set an alist for AutoBeamSetting.  When
>> it's time to do the auto-beam calculations, the code can ask the context for
>> the property setting.
> 
> Fine, but you can't make it appear to be a grob; it must be
> autoBeamSetting as a context property, which limits its syntax to `set
> [Context].autoBeamSetting = setting', unless you're proposing to
> resurrect the old style overrides for autobeaming which were removed
> some time around version 2.0.0:
> 
> \property Voice.autoBeamSettings \override #'(BE P Q N M) = dur
> 
> Which code in lily-guile.cc allows the usage you propose?  There's
> some blurb in the file related to autobeaming, but I think that's
> merely left over from the old-style autoBeamSettings code.

I think you're right.  I reviewed the parser again, and I think my initial
impression is wrong.

So why can't we define an AutoBeamPlaceHolder grob description (defined in
scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
scm/define-grob-interfaces.scm)?  It would have no engraver, but I can't see
that having an engraver is necessary for having a grob description.  And, at
least as far as I can determine, the things that are altered by \override
are special context properties called "element descriptions".  I'm not aware
of any requirement that all descriptions have to have engravers.

Of course, my knowledge of the internal details is still somewhat shadowy...


Thanks for putting up with my questions that push the boundaries...

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/14 Carl D. Sorensen :

> It seems to me to be the same to set an alist for AutoBeamSetting.  When
> it's time to do the auto-beam calculations, the code can ask the context for
> the property setting.

Fine, but you can't make it appear to be a grob; it must be
autoBeamSetting as a context property, which limits its syntax to `set
[Context].autoBeamSetting = setting', unless you're proposing to
resurrect the old style overrides for autobeaming which were removed
some time around version 2.0.0:

\property Voice.autoBeamSettings \override #'(BE P Q N M) = dur

Which code in lily-guile.cc allows the usage you propose?  There's
some blurb in the file related to autobeaming, but I think that's
merely left over from the old-style autoBeamSettings code.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/14/09 2:19 PM, "Neil Puttock"  wrote:

> 2009/4/14 Carl D. Sorensen :
>> 
>> 
>> 
>> On 4/14/09 1:39 AM, "Mats Bengtsson"  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.
> 
> I can't see how this would work at all, unless it remains a context property.
>
> In order to be a grob (even an abstract one which doesn't itself
> represent graphical elements) AutoBeamSetting would have to be created
> by an engraver; how would that work, considering that the
> Auto_beam_engraver must know where to stop and start beams *before*
> the beaming grobs are created?  You 're effectively suggesting a grob
> which will rework spanner bounds after they've been created.  You can
> do this post-processing for things like noteheads and accidentals (in
> NoteCollision and AccidentalPlacement) , since all that happens is
> repositioning of fixed-width items (i.e. Item, not Spanner, grobs).

As I understand it, the properties that are set with \override are *context*
grob properties.  That is, the place they exist is in the context, rather
than in the grob.  Then, when a grob is created, the property is extracted
from the context.  

When I do \override FretBoard #'fret-diagram-details, I'm not setting the
property of a particular FretBoard grob, I'm setting an alist in the context
that the grob_engraver will read when it's time to create the grob.

It seems to me to be the same to set an alist for AutoBeamSetting.  When
it's time to do the auto-beam calculations, the code can ask the context for
the property setting.

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/14/09 2:19 PM, "Neil Puttock"  wrote:

> 2009/4/14 Carl D. Sorensen :
>> 
>> 
>> 
>> On 4/14/09 1:39 AM, "Mats Bengtsson"  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.
> 
> I can't see how this would work at all, unless it remains a context property.

Yes, it would be a context property.

> 
> In order to be a grob (even an abstract one which doesn't itself
> represent graphical elements) AutoBeamSetting would have to be created
> by an engraver; how would that work, considering that the
> Auto_beam_engraver must know where to stop and start beams *before*
> the beaming grobs are created?  You 're effectively suggesting a grob
> which will rework spanner bounds after they've been created.  You can
> do this post-processing for things like noteheads and accidentals (in
> NoteCollision and AccidentalPlacement) , since all that happens is
> repositioning of fixed-width items (i.e. Item, not Spanner, grobs).
> 
> Property names can be nested, but you can't have what looks like an
> alist handle as a property.

Why not?

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Neil Puttock]

2009/4/14 Carl D. Sorensen :
>
>
>
> On 4/14/09 1:39 AM, "Mats Bengtsson"  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.

I can't see how this would work at all, unless it remains a context property.

In order to be a grob (even an abstract one which doesn't itself
represent graphical elements) AutoBeamSetting would have to be created
by an engraver; how would that work, considering that the
Auto_beam_engraver must know where to stop and start beams *before*
the beaming grobs are created?  You 're effectively suggesting a grob
which will rework spanner bounds after they've been created.  You can
do this post-processing for things like noteheads and accidentals (in
NoteCollision and AccidentalPlacement) , since all that happens is
repositioning of fixed-width items (i.e. Item, not Spanner, grobs).

Property names can be nested, but you can't have what looks like an
alist handle as a property.

Regards,
Neil


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

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



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/14/09 1:39 AM, "Mats Bengtsson"  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



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Mats

I guess this was addressed to Carl, as that's
exactly what I said.

Trevor

- Original Message - 
From: "Mats Bengtsson" 

To: "Trevor Daniels" 
Cc: "Carl D. Sorensen" ; "Lily-Devel List" 


Sent: Tuesday, April 14, 2009 8:39 AM
Subject: Re: Reverting Beat Grouping Commands


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

Trevor Daniels wrote:


Carl D. Sorensen wrote Monday, April 13, 2009 1:59 PM

On 4/13/09 2:44 AM, "Trevor Daniels"  
wrote:



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


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.

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.


As I understand it:

Context properties are \set and \unset and have
camelCase names without hyphens.  No grob is
involved, so no grob name is taken by \set and
\unset - just the Context name.  They have only
one value and previously set values cannot be
recovered.

Grob properties are \override-n and \revert-ed and
have hyphenated names with no capitals.  The
\override and \revert commands must always have a
grob specified, since the property is attached to
a specific type of grob.  \revert recovers the
previous value.

The existing auto-beaming rules are context
properties, but have a special function defined
for setting them due to the complex argument list
and the need (as you say) to modify a list rather
than replacing it.

You're right that \set won't add to a list, but I
don't think \override will work either, as there
is no associated grob, unless I've misunderstood
something.  Maybe a new type of grob, a bit like
NoteCollision, needs to be defined to hold the
list?  But I'm getting out of my depth here.


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

Trevor


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 Fax:   (+46) 8 790 7260
Email: mats.bengts...@ee.kth.se
WWW: http://www.s3.kth.se/~mabe
=






___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Mats Bengtsson]

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

Trevor Daniels wrote:


Carl D. Sorensen wrote Monday, April 13, 2009 1:59 PM


On 4/13/09 2:44 AM, "Trevor Daniels"  wrote:


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


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.

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.


As I understand it:

Context properties are \set and \unset and have
camelCase names without hyphens.  No grob is
involved, so no grob name is taken by \set and
\unset - just the Context name.  They have only
one value and previously set values cannot be
recovered.

Grob properties are \override-n and \revert-ed and
have hyphenated names with no capitals.  The
\override and \revert commands must always have a
grob specified, since the property is attached to
a specific type of grob.  \revert recovers the
previous value.

The existing auto-beaming rules are context
properties, but have a special function defined
for setting them due to the complex argument list
and the need (as you say) to modify a list rather
than replacing it.

You're right that \set won't add to a list, but I
don't think \override will work either, as there
is no associated grob, unless I've misunderstood
something.  Maybe a new type of grob, a bit like
NoteCollision, needs to be defined to hold the
list?  But I'm getting out of my depth here.


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

Trevor


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
   Fax:   (+46) 8 790 7260
Email: mats.bengts...@ee.kth.se
WWW: http://www.s3.kth.se/~mabe
=



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl D. Sorensen wrote Monday, April 13, 2009 5:53 PM

On 4/13/09 10:49 AM, "Graham Percival"  
wrote:


Speaking strictly from a user's point of view, why not keep the
  \set beatGrouping = #'(3 3 2)
which automatically takes the denominator of the time signature?
ok, from a code standpoint you want beatGrouping to die, so what
about
  \makeBeamGroupings #'(3 3 2)


So then we could have \makeBeamGroupings #'(3 3 2) translate into 
an
autoBeamSettings rule for the current time signature.  I like that 
idea a

lot!  Thanks!


That's more or less what I was groping towards in my
earlier mails, so I'll go along with this.

Creating a function like this might solve the problem
with \set vs \override discussed in an earlier reply.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl D. Sorensen wrote Monday, April 13, 2009 1:59 PM

On 4/13/09 2:44 AM, "Trevor Daniels"  
wrote:



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


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.

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.


As I understand it:

Context properties are \set and \unset and have
camelCase names without hyphens.  No grob is
involved, so no grob name is taken by \set and
\unset - just the Context name.  They have only
one value and previously set values cannot be
recovered.

Grob properties are \override-n and \revert-ed and
have hyphenated names with no capitals.  The
\override and \revert commands must always have a
grob specified, since the property is attached to
a specific type of grob.  \revert recovers the
previous value.

The existing auto-beaming rules are context
properties, but have a special function defined
for setting them due to the complex argument list
and the need (as you say) to modify a list rather
than replacing it.

You're right that \set won't add to a list, but I
don't think \override will work either, as there
is no associated grob, unless I've misunderstood
something.  Maybe a new type of grob, a bit like
NoteCollision, needs to be defined to hold the
list?  But I'm getting out of my depth here.


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

Trevor 




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/13/09 10:49 AM, "Graham Percival"  wrote:

> On Mon, Apr 13, 2009 at 06:59:14AM -0600, Carl D. Sorensen wrote:
>> 
>> On 4/13/09 2:44 AM, "Trevor Daniels"  wrote:
>> 
>>>  \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.
> 
> (
> 'sup dawg, I
> 
> herd u like
> 
> paragraphs
> 
> so I
> 
> paragraph'd
> 
> this
> 
> parENTHESIS.
> )

D'OH!  I shouldn't write emails when I first wake up!  I'm glad you knew
what I meant, and not what I said!

> 
> 
> 
>> Ahh -- I just thought that 8th notes are the longest notes with beams.  So
>> we could specify the *  entries as eighths, and allow fractions
> 
> I'm not totally certain about that.  I mean, I'm not certain that
> there aren't some wacky contemporary music pieces that change
> this.
> 
>> \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.
> 
> Speaking strictly from a user's point of view, why not keep the
>   \set beatGrouping = #'(3 3 2)
> which automatically takes the denominator of the time signature?
> ok, from a code standpoint you want beatGrouping to die, so what
> about
>   \makeBeamGroupings #'(3 3 2)

So then we could have \makeBeamGroupings #'(3 3 2) translate into an
autoBeamSettings rule for the current time signature.  I like that idea a
lot!  Thanks!

> and then translate that into the other stuff?  Then simple
> beamings (I consider my irregular 8/8 time to be simple :) can
> have a simple syntax, while people wanting exact control can do
> those nested list funkiness.  In their bases, of course.

All their base are belonging to me.

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Graham Percival]

On Mon, Apr 13, 2009 at 06:59:14AM -0600, Carl D. Sorensen wrote:
> 
> On 4/13/09 2:44 AM, "Trevor Daniels"  wrote:
> 
> >  \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.

(
'sup dawg, I

herd u like

paragraphs

so I

paragraph'd

this

parENTHESIS.
)



> Ahh -- I just thought that 8th notes are the longest notes with beams.  So
> we could specify the *  entries as eighths, and allow fractions
 
I'm not totally certain about that.  I mean, I'm not certain that
there aren't some wacky contemporary music pieces that change
this.

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

Speaking strictly from a user's point of view, why not keep the
  \set beatGrouping = #'(3 3 2)
which automatically takes the denominator of the time signature?
ok, from a code standpoint you want beatGrouping to die, so what
about
  \makeBeamGroupings #'(3 3 2)
and then translate that into the other stuff?  Then simple
beamings (I consider my irregular 8/8 time to be simple :) can
have a simple syntax, while people wanting exact control can do
those nested list funkiness.  In their bases, of course.

Cheers,
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/13/09 2:44 AM, "Trevor Daniels"  wrote:

> 
> 
> Carl D. Sorensen wrote Monday, April 13, 2009 1:32 AM
> 
>> On 4/12/09 6:14 AM, "Trevor Daniels" 
>> 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

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl D. Sorensen wrote Monday, April 13, 2009 1:32 AM

On 4/12/09 6:14 AM, "Trevor Daniels"  
wrote:



Carl

Standardising on a single format for auto-beaming would be a 
major
improvement, and this looks the right way to go.  But at present 
the

beatLength/beatGrouping values provide the default action in the
event of no defined beam-ending rules.  A catch-all default is
needed, as we cannot provide explicit default rules for all the
(infinite) time signatures.


The catch-all default would be implemented in auto-beaming.scm. 
If there
were no defined rule, then the denominator of the time signature 
would be

used to end the beaming, just as it currently is.


OK.  As long as we provide default rules for compound
time signatures that should be fine.

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?

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

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

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.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

I've been studying the auto-beam code to try to get to the core of what's
wrong with it, and I think I finally have it resolved.  Let me describe the
issues that I see.

1) There are three different kinds of signals for ending auto-beams.
  A) beatLength -- end a beam on the end of a beat
  B) beatGrouping -- end a beam on the end of a beat group
  C) auto-beam-setting -- end a beam when the auto-beam-setting says to.

These three different ways are potentially confusing, but we currently have
the code that handles all three.  All three can peacefully coexist, and, in
fact, all three are apparently used in the default auto-beam behavior.
However, there is a problem in that auto-beam-setting and beatGrouping are
initialized and set in two different places.

2) There is an infinite number of auto-beam-setting values that can apply in
any time signature.  This is in contrast with every other LilyPond property
with which I am familiar.  With auto-beam-settings, when you add a new
setting it doesn't replace the old setting.

I think point 2 is the major source of confusion in using
auto-beam-settings.  The user tries to create a new auto-beam-setting, but
forgets (or doesn't know) to revert an pre-existing setting.  Then, since
both settings apply, the behavior seems arbitrary to the user.

I would like to propose that we do the following:

1) Eliminate all documentation and snippets using beatLength for controlling
automatic beaming.
2) Eliminate beatGrouping for controlling automatic beaming
3) Convert auto-beam-settings to a property alist. The key would be

'(type time-signature-numerator time-signature-denominator)

For now, type would be limited to 'end (which is the current status).  In
the future, following up on Mats's (or was it Kieren's?) excellent
suggestion, we would implement 'subdivide.

The value for the alist would be another alist.  This alist would have
entries for individual beam durations, as well as a possible entry for * as
a beam duration.

So we might have default-auto-beam-settings be something like

`(
  ((end 2 2) . ((* . (,(ly:make-moment 1  2) ,(ly:make-moment 2  2)))
(32 . (,(ly:make-moment 1  4) ,(ly:make-moment 2  4)
   ,(ly:make-moment 3  4) ,(ly:make-moment 4  4
  ((end 6 8) . ((32 . (,(ly:make-moment 1 8) ,(ly:make-moment 2 8)
   ,(ly:make-moment 3 8) ,(ly:make-moment 4 8)
   ,(ly:make-moment 5 8) ,(ly:make-moment 6 8))

A '*' entry would apply to all beam lengths that weren't explicitly
specified.


The auto-beam rules that are currently handled by beatLength and
beatGrouping would be handled by the '*' entry.

In order to make it easier to do the override, I'd make a function

(make-auto-beam-setting setting-key setting-alist)

where setting-key would look like

'(end 2 2)

and setting-alist would look like

'((* . ((1 . 2) (2 . 2)))
  (32 . ((1 . 4) (2 . 4) (3 . 4) (4 . 4

The function would convert the cons cells into moments, so that the moments
wouldn't have to be recalculated every time a beam is calculated.

By making auto-beam-settings a regular alist, we should be able to do
regular \override and \revert calls.

By putting the whole set of autobeam settings of one type into a single
alist, it would take only one call to set the autobeaming however it is
desired for a given time signature.

By having the time signature in the auto-beaming-list and avoiding the use
of beatGrouping, we can avoid having settings that affect autobeaming in the
time signature change code; a change in time signature will automatically
change the autobeam settings.

Does this proposal seem reasonable?

Thanks,

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl

I would have liked to tackle this, but I think it is beyond my 
skills at the moment.  Changes will be needed to C++ code to 
implement the new beam sub-dividing at least, and I have no means of 
compiling LilyPond for testing.


Trevor

- Original Message - 
From: "Carl D. Sorensen" 
To: "Trevor Daniels" ; "lilypond-devel" 


Sent: Sunday, April 05, 2009 11:29 PM
Subject: Re: Reverting Beat Grouping Commands





On 4/5/09 3:36 PM, "Trevor Daniels"  wrote:




Carl D. Sorensen wrote Sunday, April 05, 2009 7:33 PM


What if we scrapped the current auto-beam code completely, and
replaced it
with a structured beatGrouping, something like

((denominator (ending-beatGroupings) (subdivide-beatGroupings))
 (denominator2 (ending-beatGroupings) (subdivide-beatGroupings)))



It definitely has merit!  Let's see if I understand it.
The current (ie in 2.13.1) beam-ending rules are used
only to prevent long beamed runs of 16th and 32nd beams.
Your suggestion easily accommodates all these.  For example,
in 9/4 time there are 16 rules to do this.  These could be
replaced by the far simpler

\set beatGrouping =
  #'( 8 (3 3 3) ())
(16 (4 4 4 4 4 4) ())
(32 (8 8 8 8 8 8) ()))


You're missing an opening parentheses, I think.



or rather the equivalent in scm/music-functions.scm.  We
could even improve the default by using sub-divided beams,
something we can't do at present.


So do you want to try to implement this, or do you want me
to work on it?  If you're interested, I'd just as soon have you do 
it.

But if you want me to do it, I'm willing.


I can't see anything this can't do.  If by 3/32 beams you
mean beaming 32nd notes in threes, I think it can do this.


No, I don't mean beaming 32nd notes in threes.  In the current
auto-beam-settings, there is a beam-numerator, which can be 
something other
than 1 (although I don't know what it means to have the beam 
numerator be
something else; every beam I know of has a numerator of 1).  I just 
meant
that this plan would do away with the beam numerator, and the beam 
numerator

would always be assumed to be 1.


For example, in 9/4 you'd need to modify the above to

\set beatLength = #(ly:make-moment 1 32)
\set beatGrouping =
  #'( 8 (12 12 12) ())
(16 (16 16 16 16 16 16) ())
(32 (3 3 3 3 3 3 3 3 3 3 3 3) ()))


This isn't the way I'd do it.  I would never change beatLength; for 
me,
beatLength remains the numerator of the time signature.  Also, for 
me, the
groupings for each beam type are always in the units of that beam 
type, so


\set beatGrouping =
#'(( 8 (6 6 6)())
  (16 (6 6 6 6 6 6)())
  (32 (3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3) ()))



There was a discussion some time ago about auto-
beaming east-European rhythms.  See
http://lists.gnu.org/archive/html/lilypond-user/2007-12/msg00032.html
It's getting late now, so I'll leave this until tomorrow,
but I wonder if your scheme would handle this?


I couldn't understand what the issue was in Hans's post.  I thought 
tuplets
were always beamed, and I don't know what subdivisions he wanted to 
have in

the quadruplets.

Carl




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/5/09 3:36 PM, "Trevor Daniels"  wrote:

> 
> 
> Carl D. Sorensen wrote Sunday, April 05, 2009 7:33 PM
> 
>> What if we scrapped the current auto-beam code completely, and
>> replaced it
>> with a structured beatGrouping, something like
>> 
>> ((denominator (ending-beatGroupings) (subdivide-beatGroupings))
>>  (denominator2 (ending-beatGroupings) (subdivide-beatGroupings)))
>> 
> 
> It definitely has merit!  Let's see if I understand it.
> The current (ie in 2.13.1) beam-ending rules are used
> only to prevent long beamed runs of 16th and 32nd beams.
> Your suggestion easily accommodates all these.  For example,
> in 9/4 time there are 16 rules to do this.  These could be
> replaced by the far simpler
> 
> \set beatGrouping =
>   #'( 8 (3 3 3) ())
> (16 (4 4 4 4 4 4) ())
> (32 (8 8 8 8 8 8) ()))

You're missing an opening parentheses, I think.

> 
> or rather the equivalent in scm/music-functions.scm.  We
> could even improve the default by using sub-divided beams,
> something we can't do at present.

So do you want to try to implement this, or do you want me
to work on it?  If you're interested, I'd just as soon have you do it.
But if you want me to do it, I'm willing.
> 
> I can't see anything this can't do.  If by 3/32 beams you
> mean beaming 32nd notes in threes, I think it can do this.

No, I don't mean beaming 32nd notes in threes.  In the current
auto-beam-settings, there is a beam-numerator, which can be something other
than 1 (although I don't know what it means to have the beam numerator be
something else; every beam I know of has a numerator of 1).  I just meant
that this plan would do away with the beam numerator, and the beam numerator
would always be assumed to be 1.

> For example, in 9/4 you'd need to modify the above to
> 
> \set beatLength = #(ly:make-moment 1 32)
> \set beatGrouping =
>   #'( 8 (12 12 12) ())
> (16 (16 16 16 16 16 16) ())
> (32 (3 3 3 3 3 3 3 3 3 3 3 3) ()))

This isn't the way I'd do it.  I would never change beatLength; for me,
beatLength remains the numerator of the time signature.  Also, for me, the
groupings for each beam type are always in the units of that beam type, so

\set beatGrouping =
#'(( 8 (6 6 6)())
   (16 (6 6 6 6 6 6)())
   (32 (3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3) ()))

> 
> There was a discussion some time ago about auto-
> beaming east-European rhythms.  See
> http://lists.gnu.org/archive/html/lilypond-user/2007-12/msg00032.html
> It's getting late now, so I'll leave this until tomorrow,
> but I wonder if your scheme would handle this?

I couldn't understand what the issue was in Hans's post.  I thought tuplets
were always beamed, and I don't know what subdivisions he wanted to have in
the quadruplets.

Carl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl D. Sorensen wrote Sunday, April 05, 2009 7:33 PM

What if we scrapped the current auto-beam code completely, and 
replaced it

with a structured beatGrouping, something like

((denominator (ending-beatGroupings) (subdivide-beatGroupings))
 (denominator2 (ending-beatGroupings) (subdivide-beatGroupings)))

We might then have something like the following in 6/8 time:

((8 (3 3) ())
 (16 (6 6) (6 6))
 (32 (4 4 4 4 4 4) (8 8 8)))

Then, if subdivideBeams  were set to #t, we could reduce the beam 
count for

a given level of beaming at the appropriate point.

I don't know if this is a better solution, but it might improve 
what

currently seems to me to be a very awkward system.

One weakness in this approach is that it provides no way to have 
an
auto-beam-ending rule for 3/32 beams (but I don't know of any 3/32 
beams, so

I don't think that's a real limitation).

David Brobroff's request

could then be met by

((8 (4) ())
 (16 (4 4) ())
 (32 (8 8) (4 4 4 4)))

This would have the downside of requiring a complete redefinition 
every time
you changed the time signature, but it would get rid of the 
current problem
where you have to revert rules before you can add new ones.  It 
would also
put all automatic definitions of autobeam rules in one location in 
the

source tree, rather than having them spread across two files.

I don't know if this proposal has merit or not, but it seems like 
we really
ought to get to *some* combination of syntax and functionality 
that we think

really works.


It definitely has merit!  Let's see if I understand it.
The current (ie in 2.13.1) beam-ending rules are used
only to prevent long beamed runs of 16th and 32nd beams.
Your suggestion easily accommodates all these.  For example,
in 9/4 time there are 16 rules to do this.  These could be
replaced by the far simpler

\set beatGrouping =
 #'( 8 (3 3 3) ())
   (16 (4 4 4 4 4 4) ())
   (32 (8 8 8 8 8 8) ()))

or rather the equivalent in scm/music-functions.scm.  We
could even improve the default by using sub-divided beams,
something we can't do at present.

I can't see anything this can't do.  If by 3/32 beams you
mean beaming 32nd notes in threes, I think it can do this.
For example, in 9/4 you'd need to modify the above to

\set beatLength = #(ly:make-moment 1 32)
\set beatGrouping =
 #'( 8 (12 12 12) ())
   (16 (16 16 16 16 16 16) ())
   (32 (3 3 3 3 3 3 3 3 3 3 3 3) ()))

There was a discussion some time ago about auto-
beaming east-European rhythms.  See
http://lists.gnu.org/archive/html/lilypond-user/2007-12/msg00032.html
It's getting late now, so I'll leave this until tomorrow,
but I wonder if your scheme would handle this?

Trevor




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/5/09 9:02 AM, "Trevor Daniels"  wrote:

> 
> 
> Carl D. Sorensen wrote Sunday, April 05, 2009 3:16 PM
> 
>> On 4/5/09 5:05 AM, "Trevor Daniels"  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?
> 
> My objective is to make it as simple as possible for people
> to use beat-grouping.  At the moment they have to understand
> how to turn off the beam-ending rules with revert first, and
> they would still need to understand this even with a revert-all
> function.  What I'm proposing is a simpler way for those who
> don't what to get into the beam-ending rules - we simply say
> "to use beat grouping, \set useBeamEndingRules to ##f".

beatGrouping and auto-beam-ending-rules are not currently mutually
exclusive.  Do we want to make them mutually exclusive?  I honestly don't
know the answer to this question.  I added beatGrouping to the auto-beam
code because the lack of it was a known issue.  I don't know what the
"right" thing to do is.

Currently, in scm/auto-beam.scm, the default auto-beam-settings make use
of beatLength, beatGrouping, and explicit settings.  If they are cleanly
separated, I think we'll need to adjust that significantly.

One advantage to your proposal is that we wouldn't have to eliminate the
default auto-beam settings.  The revert-all-auto-beam-settings would
eliminate the rules from the list, and there's no way to get them back.

Is it possible that one would want to use beatGrouping for one time
signature but use auto-beam-ending rules for another time signature?  Would
an entry ((end * * num den) . 'ignore)  be a useful way to ignore all
auto-beam ending rules that would be revertable?
 
> 
> Those writing their own beam-ending rules -have- to understand
> them, so they should have no difficulty using a revert.
> 
>> 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.
> 
> No it's not hard to write, but the documention would be
> much simpler if we can clearly separate the two methods.

This is probably true.  But the code doesn't currently clearly separate the
two methods.  If we want to have the two methods be mutually exclusive, the
code should be changed.  It would actually greatly simplify the code to have
beatGrouping ignore the auto-beam settings.

What if we scrapped the current auto-beam code completely, and replaced it
with a structured beatGrouping, something like

((denominator (ending-beatGroupings) (subdivide-beatGroupings))
 (denominator2 (ending-beatGroupings) (subdivide-beatGroupings)))

We might then have something like the following in 6/8 time:

((8 (3 3) ())
 (16 (6 6) (6 6))
 (32 (4 4 4 4 4 4) (8 8 8)))

Then, if subdivideBeams  were set to #t, we could reduce the beam count for
a given level of beaming at the appropriate point.

I don't know if this is a better solution, but it might improve what
currently seems to me to be a very awkward system.

One weakness in this approach is that it provides no way to have an
auto-beam-ending rule for 3/32 beams (but I don't know of any 3/32 beams, so
I don't think that's a real limitation).

David Brobroff's request

could then be met by

((8 (4) ())
 (16 (4 4) ())
 (32 (8 8) (4 4 4 4)))

This would have the downside of requiring a complete redefinition every time
you changed the time signature, but it would get rid of the current problem
where you have to revert rules before you can add new ones.  It would also
put all automatic definitions of autobeam rules in one location in the
source tree, rather than having them spread across two files.

I don't know if this proposal has merit or not, but it seems like we really
ought to get to *some* combination of syntax and functionality that we think
really works.


> 
>> 
>> 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.
> 
> The consideration isn't a count of the number of properties
> but whether Lily becomes easier to use or not.  I think a \set
> command -is- easier to use, and the documentation would certainly
> be easier to write and understand if we can relegate all
> consideration of the beam-ending rules to just those who
> actually

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Carl D. Sorensen wrote Sunday, April 05, 2009 3:16 PM


On 4/5/09 5:05 AM, "Trevor Daniels"  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?


My objective is to make it as simple as possible for people
to use beat-grouping.  At the moment they have to understand
how to turn off the beam-ending rules with revert first, and
they would still need to understand this even with a revert-all
function.  What I'm proposing is a simpler way for those who
don't what to get into the beam-ending rules - we simply say
"to use beat grouping, \set useBeamEndingRules to ##f".

Those writing their own beam-ending rules -have- to understand
them, so they should have no difficulty using a revert.


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.


No it's not hard to write, but the documention would be
much simpler if we can clearly separate the two methods.

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

outline of it?


No thanks, I'm pretty sure I can write it.  But I wonder
if this is really the best approach.


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.


The consideration isn't a count of the number of properties
but whether Lily becomes easier to use or not.  I think a \set
command -is- easier to use, and the documentation would certainly
be easier to write and understand if we can relegate all
consideration of the beam-ending rules to just those who
actually need their complexity.

That said, I'm happy to do either (or both) depending on your
and others' views.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Carl D. Sorensen]

On 4/5/09 5:05 AM, "Trevor Daniels"  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




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

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


Trevor


- Original Message - 
From: "Carl D. Sorensen" 
To: "Trevor Daniels" ; "lilypond-devel" 


Sent: Monday, March 23, 2009 1:14 AM
Subject: Reverting Beat Grouping Commands


Trevor,

Here is the code that I remembered had been provided for reverting 
auto-beam

settings.

Unfortunately, I remembered it coming from Nicolas instead of Neil. 
I
guess I got my Scheme-guru-beginning-with-N names confused.  Sorry, 
Neil!


HTH,

Carl


-- Forwarded Message
From: Neil Puttock 
Date: Sat, 25 Oct 2008 14:06:42 -0600
To: Trevor Daniels 
Cc: "Carl D. Sorensen" , Lilypond-User List

Conversation: Beat grouping and reverting
Subject: Re: Beat grouping and reverting

Hi Trevor,

2008/10/25 Trevor Daniels :

Carl

But how do you revert entries like this:

((end * * 6 8) . #f) ;; switch-off at-any-beat feature


The simplest way would be to add a function to switch this back on:

#(define (revert-property-setting context property setting)
 "Like the C++ code that executes \revert, but without type
checking. "
 (define (revert-member alist entry new)
   "Return ALIST, with ENTRY removed.  ALIST is not modified, 
instead

a fresh copy of the list-head is made."
   (cond
((null? alist) new)
((equal? (car alist) entry) (revert-member (cdr alist) entry 
new))
(else (revert-member (cdr alist) entry (cons (car alist) 
new)

 (ly:context-set-property!
  context property
  (revert-member (ly:context-property context property) setting 
'(


#(define (allow-at-any-beat num den)
 (ly:export
  (context-spec-music
   (make-apply-context (lambda (c)
 (revert-property-setting
  c 'autoBeamSettings
  (cons `(end * * ,num ,den) #f
   'Voice)))

\relative c'' {
 #(set-time-signature 6 8 '())
 #(allow-at-any-beat 6 8)
 #(revert-auto-beam-setting '(end * * 6 8) 3 8)
 #(revert-auto-beam-setting '(end 1 32 6 8) 1 8)
 #(revert-auto-beam-setting '(end 1 32 6 8) 1 4)
 #(revert-auto-beam-setting '(end 1 32 6 8) 1 2)
 #(revert-auto-beam-setting '(end 1 32 6 8) 5 8)
 a8 a a a a a
 \set beatGrouping = #'(2 2 2)
 a8 a a a a a
}

A better solution might be to rewrite revert-auto-beam-setting so 
that

the args for beat begin/end are moved to the optional argument list
(which is currently only used for the context).

Regards,
Neil

-- End of Forwarded Message




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Reverting Beat Grouping Commands

[Trevor Daniels]

Ahh, right.  Thanks Carl.

This doesn't actually do what I wanted, but it
does show me how to go about it.  I'll see if
I can develop this into a Scheme function to
revert all the autoBeamSettings in a given
time signature.  My first frog assignment!

It might take some time ...

Trevor

- Original Message - 
From: "Carl D. Sorensen" 
To: "Trevor Daniels" ; "lilypond-devel" 


Sent: Monday, March 23, 2009 12:14 AM
Subject: Reverting Beat Grouping Commands


Trevor,

Here is the code that I remembered had been provided for reverting 
auto-beam

settings.

Unfortunately, I remembered it coming from Nicolas instead of Neil. 
I
guess I got my Scheme-guru-beginning-with-N names confused.  Sorry, 
Neil!


HTH,

Carl


-- Forwarded Message
From: Neil Puttock 
Date: Sat, 25 Oct 2008 14:06:42 -0600
To: Trevor Daniels 
Cc: "Carl D. Sorensen" , Lilypond-User List

Conversation: Beat grouping and reverting
Subject: Re: Beat grouping and reverting

Hi Trevor,

2008/10/25 Trevor Daniels :

Carl

But how do you revert entries like this:

((end * * 6 8) . #f) ;; switch-off at-any-beat feature


The simplest way would be to add a function to switch this back on:

#(define (revert-property-setting context property setting)
 "Like the C++ code that executes \revert, but without type
checking. "
 (define (revert-member alist entry new)
   "Return ALIST, with ENTRY removed.  ALIST is not modified, 
instead

a fresh copy of the list-head is made."
   (cond
((null? alist) new)
((equal? (car alist) entry) (revert-member (cdr alist) entry 
new))
(else (revert-member (cdr alist) entry (cons (car alist) 
new)

 (ly:context-set-property!
  context property
  (revert-member (ly:context-property context property) setting 
'(


#(define (allow-at-any-beat num den)
 (ly:export
  (context-spec-music
   (make-apply-context (lambda (c)
 (revert-property-setting
  c 'autoBeamSettings
  (cons `(end * * ,num ,den) #f
   'Voice)))

\relative c'' {
 #(set-time-signature 6 8 '())
 #(allow-at-any-beat 6 8)
 #(revert-auto-beam-setting '(end * * 6 8) 3 8)
 #(revert-auto-beam-setting '(end 1 32 6 8) 1 8)
 #(revert-auto-beam-setting '(end 1 32 6 8) 1 4)
 #(revert-auto-beam-setting '(end 1 32 6 8) 1 2)
 #(revert-auto-beam-setting '(end 1 32 6 8) 5 8)
 a8 a a a a a
 \set beatGrouping = #'(2 2 2)
 a8 a a a a a
}

A better solution might be to rewrite revert-auto-beam-setting so 
that

the args for beat begin/end are moved to the optional argument list
(which is currently only used for the context).

Regards,
Neil

-- End of Forwarded Message




___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel