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

[Jean Abou Samra]

Le mercredi 22 mars 2023 à 13:50 -0500, Jason Yip via Discussions on LilyPond 
development a écrit :
> 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

(Just so you know, they weren't on GitLab at the time, the project migrated 
from SourceForge in 2020)

> and Urs Liska's  
> analysis at
> [https://gitlab.com/lilypond/lilypond/uploads/a4eecb716f9b52ae90da814612ea00a9/beam-subdivisions.pdf](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?


(Not commenting because I haven't looked into this yet.)

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

If you change the interface of beaming-pattern.cc, it may necessitate adapting 
beam-engraver.cc and auto-beam-engraver.cc.

In general, it is good if you have an idea of how the overall system works, 
even if you're not familiar with the details.

>   * 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`

Generally speaking, you can't really approach LilyPond with a "I know C++, so I 
can touch any C++ code" mindset (it works somewhat better the other way, i.e. 
contribute in Scheme without knowing C++). Because LilyPond's C++ is very much 
interwoven with Scheme. In this case,

- You may need/want to modify scm/auto-beam.scm. For example, adding support 
for specifying beam subdivisions in beam exceptions.

- The C++ code itself interacts with Scheme data structures:

```
$ rg -i "scm" lily/beaming-pattern.cc 
200:find_location (SCM grouping, Rational base_moment, Rational start_moment,
214:      if (scm_is_pair (grouping))
216:          group_count = from_scm<int> (scm_car (grouping));
217:          grouping = scm_cdr (grouping);
246:  SCM grouping = options.grouping_;
431:  subdivide_beams_ = from_scm<bool> (get_property (context, 
"subdivideBeams"));
433:    = from_scm<bool> (get_property (context, "strictBeatBeaming"));
435:    = from_scm (get_property (context, "baseMoment"), Moment (1, 
4)).main_part_;
437:    = from_scm (get_property (context, "measureLength"), Moment (4, 4))
443:  grouping_ = SCM_EOL;
451:  scm_gc_mark (grouping_);
```

`SCM` values are Scheme values, `scm_*` functions are defined by Guile.

Therefore, I would expect your project to involve some time to learn at least 
basic Scheme and basic Guile C APIs.


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

Yes, please do.

Best,

Jean

signature.asc
Description: This is a digitally signed message part