lilypond-devel
[Top][All Lists]
Advanced

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

Re: Autobeaming


From: Carl Sorensen
Subject: Re: Autobeaming
Date: Tue, 29 Dec 2009 16:17:00 -0700



On 12/29/09 3:06 PM, "Hans Aberg" <address@hidden> wrote:

> 
> 
> On 29 Dec 2009, at 22:00, Carl Sorensen wrote:
> 
>>>> Does this seem like a feasible architecture?
>>> 
>>> I think a system that determines the [meter] from the time signature
>>> is fundamentally flawed. I think in terms of a \meter that can be
>>> used
>>> to define the beaming structure. I substructure of that is summed up,
>>> and written as a time signature. If one has defined a set of such
>>> time
>>> signatures, then one can use that for a lookup.
>> 
>> I believe that is what I am proposing.  Instead of trying to calculate
>> beatLength and measureGrouping from the time signature, we set them,
>> along
>> with intended beamGrouping.  That way, the meter is determined by
>> the user,
>> rather than inferred by the code.
> 
> I find the current LilyPond structure hard to cope with when wanting
> subbeaming. 

Yes, right now there is no sound method for dealing with subbeaming (or beam
subdivision, as I think it's called).  I hope to fix that.

> Also, some beaming wanted for that was discussed on the
> LilyPond lists in the past breaks the simple idea of beaming
> expressing a hierarchy of metric accents - though I do not want
> anything that. My interpretation of it is like this, though I found it
> hard to express formally:
> 
> The smallest units is "in one", where one only has a time segment
> which should be beamed as much as possible - on the time level
> subdivision it expresses.

Ross and Read talk about this smallest unit as a "beat", and it is not
necessarily the denominator of the time signature.  In fact, in what they
refer to as "compound time" or "compound meter", the beat is three times the
denominator of the time signature.

> 
> Then one can repeat that either equally by an integer multiple or a
> "+". For example, 6/8 calls for a "in one" 3+3 division of the time
> unit which is the 1/8th note, which at the same time is the same as 2
> times the dotted 1/4th note. So doing some pseudocode, it might be
> written
>    (3+3) x 1/8
> or
>    2 x 3/8 = 2 x 1/4. (dotted 1/4th)
> 
> However, in the first one, the 3's should be "in one", and not be
> beamed as "in three", expressing metric subaccents. So perhaps one
> needs to distinguish between these two types of integers, say write
> "in one" as 3'. Then the first one should be written
>    (3'+3') x 1/8

So if I understand correctly, you mean that all the notes in each of the 3'
sections should be beamed together, thus avoiding metric subaccents?

> 
> Then take a time signature like 4/4. It has i fact two common
> interpretations:
>    (2'+2') x 1/4
>    4 x 1/4
> 
> Now one might also use tuplets tied to the metric. For example, in
> Macedonian 7/16, one may normally play as
>    (3'+(2'+2')) x 1/16
> But one may shift to using quadruplets on the 3s divided as 2'+2',
> which one might want to express in the subbeaming. So one might want a
> second rule like
>    (3:4 (2'+2') + (2'+2')) x 1/16
> So the \meter should have a sequence of such rules.

I believe that these rules are exactly what the current autobeaming rules
can express (although the rules that express this are not in the current
default beam settings).

> 
> When writing a time signature, some may want to just adding it all in
> one number, and other want to write a "+", Bartok style. That might be
> described by replacing some of the (..) with [..] on one of the rules.
> For example
>    [3'+(2'+2')] x 1/16
> would be written as
>     7
>    16
> But there is a problem already here, as one might want to writ it as
>    3+2+2
>     16
> even though the beaming is (3'+(2'+2')). Writing
>    [3'+[2'+2']] x 1/16
> would strictly speaking lead to a time signature
>    3+(2+2)
>      16
> though it is probably uncommon to have (..) in the time signature.
> 

I believe we currently have the capability of writing compound time
signatures (which governs the display of the time signature).  With the new
properties, we'll be able to set the measure grouping and the beaming
characteristics, so I think the full flexibility will be there.


> I think some may then want to write a different time signature than
> what is strictly implied by the beaming.
> 
> Together with the defined has defined a \meter structure, one needs to
> also specify how it should be rendered. On the top level, it might
> express a meter change between measures, using various dotted bars
> ":", then comes space break, and after that some subbeaming.
> 
> So that is roughly how I think about it. - LilyPond has some of it,
> but I think cannot express that hierarchy properly in a suitable human
> interface.

The human interface in LilyPond is likely to continue to be sub-optimal at
least for the near future.  But I believe that in the near future the
capability to display the appropriate time signatures, measure grouping,
beaming, and subbeaming will be present.

Thanks,

Carl





reply via email to

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