[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Interested in GNU Lilypond Google Summer of Code Beaming Fixing
Re: Fwd: Interested in GNU Lilypond Google Summer of Code Beaming Fixing Project Idea
Wed, 22 Mar 2023 13:50:41 -0500
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 `beaming-pattern.cc`.
From my understanding of past GitLab issue discussions and Urs Liska's
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/beaming-pattern.cc` 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 `beaming-pattern.cc` 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
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
On 2023-03-20 14:27, Carl Sorensen - carl.d.sorensen(a)gmail.com wrote:
This email failed anti-phishing checks when it was received by SimpleLogin, be
careful with its content.
More info onhttps://simplelogin.io/docs/getting-started/anti-phishing/
Forwarding to list, since I apparently didn't add the list to the email as
I intended to.
---------- Forwarded message ---------
From: Carl Sorensen<firstname.lastname@example.org>
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<email@example.com>
Thanks for your interest!
On Sun, Mar 19, 2023 at 12:21 AM Jason Yip<firstname.lastname@example.org>
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
beaming-pattern.cc to “beat”, and “beat” in beaming-pattern.cc 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 beaming-pattern.cc, 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 email@example.com 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
Description: OpenPGP public key
Description: OpenPGP digital signature