Re: Terminology of baseMoment, beats, groups

[Urs Liska]

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
> > long.
> >
> > 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
> > quavers.
> >
> >
> > b) from beaming-pattern.cc
> >
> > 1) line 206ff., comment to find_location()
> > /*
> >     Get the group start position, the next group starting position, and
> > the
> >     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.

Exactly.

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

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

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

> When I look at http://openmusictheory.com/meter.html , 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.

Best
Urs


> Thanks,
>
> Carl