[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: Jean Abou Samra
Subject: Re: Fwd: Interested in GNU Lilypond Google Summer of Code Beaming Fixing Project Idea
Date: Wed, 22 Mar 2023 21:04:41 +0100
User-agent: Evolution 3.46.4 (3.46.4-1.fc37)

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 ``.
>  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
> [](,
> 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/` 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.

If you change the interface of, it may necessitate adapting and

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

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/ 
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, 
433:    = from_scm<bool> (get_property (context, "strictBeatBeaming"));
435:    = from_scm (get_property (context, "baseMoment"), Moment (1, 
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.



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

reply via email to

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