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

[Jason Yip]

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 `beaming-pattern.cc`.

From my understanding of past GitLab issue discussions and Urs Liska's 
analysis at 
https://gitlab.com/lilypond/lilypond/uploads/a4eecb716f9b52ae90da814612ea00a9/beam-subdivisions.pdf, 
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
   rewritten `beaming-pattern.cc`

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)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<carl.d.sorensen@gmail.com>
> 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<sripedia_getpgrp@slmail.me>
>
>
> Jason,
>
>
> Thanks for your interest!
>
>
>
>
>
> On Sun, Mar 19, 2023 at 12:21 AM Jason Yip<sripedia_getpgrp@slmail.me>
> wrote:
>
> > 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
> in beaming-pattern.cc
>
>
>
> 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
> documentation:
>
> https://lists.gnu.org/archive/html/lilypond-devel/2017-11/msg00037.html
>
>
>
> 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 addedlilypond-devel@gnu.org  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
> processes.
>
>
> If you'd like some help in getting started on the terminology change
> project, please let me know.
>
>
> Thanks,
>
>
> Carl
>
>
>
>
>
> I
--
- Jason Yip

OpenPGP_0xB69A3DD87D22F506.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature