[Top][All Lists]

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

Re: Fwd: Interested in GNU Lilypond Google Summer of Code Beaming Fixing

From: Jason Yip
Subject: Re: Fwd: Interested in GNU Lilypond Google Summer of Code Beaming Fixing Project Idea
Date: Wed, 22 Mar 2023 13:50:41 -0500

Hi everyone,

In the past 2 days, I have spent my time investigating the many GitLab issues related to regular note/tuplet subdivision problems and reading the Contributor's documentation and related C++ files. I am somewhat close to completing a GSoC application draft, and would like to share some ideas on how to approach rewriting ``.

From my understanding of past GitLab issue discussions and Urs Liska's analysis at, it seems that the `beatStructure`/`beatMoment` properties stubbornly stay the same when dealing with deeply nested groupings of notes to be beamed. I think that I can rewrite each `Beam_rhythmic_element` to act as a tree node so that children note groupings would be able to have their own appropriate values for those properties. Treating the beaming process as a recursive tree should also fix some issues with complex tuplets somewhat. `Beaming_rhythmic_element` may need another context property `subdivisionInterval` for correct beaming as suggested in page 3 of Liska's analysis (I'm not sure if it's even necessary with my tree approach). I'm trying to understand `rhythmic_importance` and how it can work with my tree idea.

Any thoughts on my above approach?

I also have some things I want to clarify:

 * I know `lily/` will have to be rewritten from
   scratch (plus its header file will have to be touched up). Are there
   any other C++ files that need to be fixed/rewritten to work with
   modifications to `` in the scope of this project?
   I analyzed the other files `lily/*beam*.cc` and they don't really
   have much responsibility in deciding beat/tuplet structures. But a
   couple of files rely on the `baseMoment`, `beatStructure`,
   `beamExceptions` context properties.
 * I'm not sure how to work with the Scheme code, but does the Scheme
   code simply treat C++ backend functions as a black-box API (meaning
   I don't have to do much to deal with the Scheme part of Lilypond)?
   Or would I have to modify parts of Scheme code to work with the
   rewritten ``

Once I fully understand the above, I'll be able to deal with the last parts of my GSoC application.

I have taken some notes to try to aggregate information related to this bug; I'd be happy to share them if it helps.

Hope that my skills and ideas will be of use, I'm looking forward to this project!

On 2023-03-20 14:27, Carl Sorensen - carl.d.sorensen(a) wrote:
This email failed anti-phishing checks when it was received by SimpleLogin, be 
careful with its content.
More info on
Forwarding to list, since I apparently didn't add the list to the email as
I intended to.

---------- Forwarded message ---------
From: Carl Sorensen<>
Date: Mon, Mar 20, 2023 at 12:59 PM
Subject: Re: Interested in GNU Lilypond Google Summer of Code Beaming
Fixing Project Idea
To: Jason Yip<>


Thanks for your interest!

On Sun, Mar 19, 2023 at 12:21 AM Jason Yip<>

Hello Carl,

My name is Jason Yip, and I am interested in learning more about GNU
Lilypond's "Fix Beaming Patterns/Beam Subdivisions and Tuplets" project
idea for Google Summer of Code and participating in this project idea. I
would like to ask, are you are still looking for prospective 2023 GSoC
contributors for this project idea?

I am currently a 2nd year student at University of Illinois at
Urbana-Champaign, US and I am studying Computer Science + Music. I have
some basic familiarity with LilyPond as I sometimes use it to create
personal scores. I have about 4 years of experience in C++, which I hope
will be of use. I am available to contribute full-time during the summer
and would like to explore this issue, even if it means refactoring a lot
of the Beam C++ classes.

The beaming project would be a great asset to LilyPond.  I’d love to see
you tackle it, if you’re interested.  Your background in C++  would be a
great asset here.

In preparation for submitting a proposal, it might be good to rename things

There is a discussion on the lists (wow, from 5 ½ years ago!) that mentions
the names used in the code don’t match the names used in the user

The bottom line on that discussion is that we could change “group” in to “beat”, and “beat” in to “
base_moment” to match our user documentation.  I would expect that making
this change would do two things:

    1. Get you an introduction to, which is where the
    major work needs to be done, and
    2. Get you an introduction to our process for handling merge requests,
    which would make you part of the team.

I've  on the reply, in order to get you
introduced to the development group.

I'd also suggest that you look at the LilyPond Contributor's Guide, which
is where we keep all the available information about our development

If you'd like some help in getting started on the terminology change
project, please let me know.




- Jason Yip

Attachment: OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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