Urs,
Here's an old email that discusses a proposed different structure for setting
beaming characteristics.
The thing that caused me to see this as the most promising is it has settings
for both beat grouping (i.e. how to combine beamed notes into groups) and beat
subdivision (i.e. how to subd
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 sim
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.
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 p
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
fo
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,
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 overrid
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 wan
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 mai
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_propert
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; i
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 engrave
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 necess
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 appe
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 p
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 gra
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 gra
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 #'prop
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 Obj
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
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
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 natu
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
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
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
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 s
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 user
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 defau
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) beat
arl 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 scrapp
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-
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-beat
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 pr
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?
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 co
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 fo
..
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
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 Putt
38 matches
Mail list logo
