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