[Top][All Lists]

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

Re: Terminology of baseMoment, beats, groups

From: Urs Liska
Subject: Re: Terminology of baseMoment, beats, groups
Date: Sat, 11 Nov 2017 21:14:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

Hi Carl,

Am 11.11.2017 um 15:30 schrieb Carl Sorensen:
On 11/11/17 4:00 AM, "lilypond-devel on behalf of Urs Liska"
<address@hidden on behalf of
address@hidden> wrote:

a) from the NR section linked
"beatStructure is a scheme list that defines the length of each beat in
the measure in units of baseMoment. "

I read this as: In the given example beatStructure is a list that
defines the measure to consist of three beats. Beat one and two have the
length of three baseMoments of 1/8, beat three is two baseMoments of 1/8

Actually this is consistent with how I would describe that measure in
prose: we have an 8/8 measure with three beats, with lengths 3, 3, and 2

b) from

1) line 206ff., comment to find_location()
    Get the group start position, the next group starting position, and
    next beat starting position, given start_moment, base_moment,
    grouping, and factor

2) line 265, comment right after find_location has been called:
// Mark the importance of stems that start at a beat or a beat group.

 From the actual behaviour of the code (and other comments throughout
the code) it is clear that "beat" refers to a baseMoment unit and
"group" refers to the entity the NR calls "beat".
The context property "beatStructure" obviously corresponds to the C++
variable "grouping".
Urs, you are absolutely correct about this.

Thank you for the confirmation.

As far as I know, I was the
last person to make major revisions to the beaming code (of course,
David's work to allow a music expression to enter beat structures came
after my work).

I think I was the last person to make revisions to the code but you were the last whose work is actually in master ;-)

When I started complaining about beam subdivisions you provided a few patches. When it turned out that every patch would lead to further problematic output I started working on it with the goal of doing it properly (the last state of that can still be found on the dev/urs/subdivide-beams branch). But I didn't manage to finish it then, which I now think had a few reasons:
- the task was generally somewhat over my head
- specifically it was my first actual attempt at doing something in C++
- the existing code is definitely not the ideal environment for making first experiences in C++, and (most fundamentally)
- I had also worked by fixing problems when I encountered them.

That's why I'm now working on a conceptual assessment first before even thinking about touching the code again. It should be possible to reduce the need to deal with special cases as much as possible by finding the right reference points in the first place.

In the code that I started working on, there were beats and beat
groupings.  The beat corresponds to what is now called a baseMoment, and
the beat grouping corresponds to the musical beat.


When I was working on this, I had a very poor musical understanding of
rhythm; it was more of an engineer's understanding of rhythm.  Glue some
baseMoments together to get a beat group.  In my defense, that's what was
already in the code, so I was just building on it.

I think it would be great to move toward something that makes more sense

I think that the beatStructure concept and terminology is pretty adequate musically.

We ought to be able to capture the idea of simple duple,
simple triple, simple quadruple, compound duple, compound triple, compound
quadruple. Of course, to handle modern music, we also need to handle other
kinds of rhythms and beats.

I still think the beatStructure is adequate, but it may be very helpful to add syntactic sugar to ask for such standard situations more easily. This would be on the user level while keeping the underlying data structures as they are.

The code has no inherent understanding of compound meters and how one
would treat them different from simple meters.  So we tried to fix this
with the beatStructure property.  But maybe that's not the best thing

I'm not sure about that. AFAICS beatStructure works well but could get more user-friendly by syntactic sugar.

When I look at , the thing that we
call a beat in the c++ code is what openmusictheory calls a pulse.  And
what we call a beat group is what they call a beat.  In this context,
baseMoment is the length of a pulse.  And beatStructure defines the
lengths of each beat in the measure in pulses.  It would be a
straightforward first step to replace "beat" with "pulse", and "beat
group" with "beat" in both the c++ and scm code.

While I've never heard that term in this context I agree that pulse and beat are good names for the things in question, and I suggest to rename them in the code (while it shouldn't change anything in the user-facing syntax). However, I wouldn't actually do that as an independent patch but in the context of a more general reworking.

As far as I'm concerned, a complete refactoring of the LilyPond beaming
code and concepts is perfectly acceptable.  It's always good to get things
right, rather than to just hack them.

I hoped that such a refactoring could essentially be limited to the beaming-pattern code (and ignore the beaming itself that happens before that), but it seems that will not be possible. As I reported on bug-lilypond I noticed that the actual beaming seems to suffer from the same limitations as beam subdivisions when it comes to tuplets. I haven't looked into the beam-engraver code yet, but from the engraving results I have the impression it's the same misconception at work.

I'm happy to serve as a team member working with you on this, but I can
probably only spend a few hours per week.  But I think we could probably
get this to work right, which would enable us to do proper subdivision.

That's great to hear.
As stated I'm not sure if I will be able to actually start working on this and therefore wanted to at least create an assessment to ensure my experiences won't get lost. Of course I'll share that when I'm initially through with it. The actual work on the code looks like it isn't that much and even complicated - as long as there is a good (and common) understanding of the concepts, names and intended results.




reply via email to

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