Thanks, Jason.
See my answers below.
Carl
From: Jason Yip <sripedia_getp...@slmail.me>
Date: Wednesday, March 29, 2023 at 8:45 PM
To: Carl Sorensen <carl.d.soren...@gmail.com>
Cc: Devel <lilypond-devel@gnu.org>
Subject: Preferred Mentor-Mentee Communication, Plan for Auto-Beaming Project
Hi Carl,
I'm CC'ing the developers mailing list, just to let you know.
I would like to first ask you about your preferred mode of communication, if my
project proposal is selected. That is, what modes of communication would you
prefer for:
* Real-time communication for mentor-mentee matters
I would probably prefer phone or text, but can use Discord, IRC, or various
videoconferencing systems. I prefer phone or text because I typically always
have my phone with me but I’m not always at my computer. But I’m willing to
work out something that will work with you.
* Quick/casual communication among all the developers concerning my general
project progress
Lilypond-devel mailing list
* Communication concerning bug reports, code reviews, etc. related to my
project, whether it be casual or for the general public
Liliypond-devel mailing list
If these answers aren’t good for you, let’s have more of a conversation.
Secondly, I have drafted a 12-week plan to go with my proposal (hopefully the
markdown formats nicely):
This schedule seems a bit over-aggressive. But I think it’s good for a stretch
goal.
- Weeks 0-3 (May 29-Jun 16)
- Implement regular note subdivision beaming functionality/C++ class
structures
- Learn other C++ components that integrate with beam/subdivision code
- Modify enough Scheme code to work with new code
I haven’t looked at it carefully, but I think that the Scheme code just calls
beaming-pattern.cc to do the hard work of beaming patterns, so I think that by
and large fixing the C++ will fix the beaming subdivision problems.
There will likely need to be some new properties defined (that will involve
some Scheme procedures.
- Work on changing a few but critical test cases that work with my
rewritten code if necessary
I’d have you make sure that you have failing regression tests for all of the
beaming features you hope to implement. The regression tests will provide the
best specification for success you could have. And having them fail is no
problem at this stage.
- End of Week 3 (Jun 16)
- C++ Code infrastructure for regular note subdivision should be complete
(obviously can't be 100% perfect)
I love that you are starting on regular note subdivision. I think that’s a
great starting point.
But I think you should have a vision for how tuplets are going to work before
refactoring the regular beaming code. You should have confidence that your
code is compatible with your planned tuplet work.
- Scheme code should have basic refactoring
- Documentation covering beaming should be modified to align with my code
by this point, but I may need the next few weeks to complete this part of the
documentation
When you have the regression tests working, the documentation should be pretty
straightforward. In the NR, we don’t try to be a tutorial; we try to be a
reference. So basically we define a behavior that can be accomplished and show
how it is done with a snippet.
- Weeks 4-6 (Jun 19 - Jul 7)
- Personal Vacation during weeks 5-6 (Jun 26 - Jul 7), so workload will be
reduced
Good for you scheduling a vacation!
- Ensure that my fixed code resolves most common complaints from old GitLab
issues affected by this bug/backward compatibility
This will be easily done by having your broken regression tests written earlier
- Rewrite/refactor the most important/critical regression tests
IMO should have been done earlier.
- Wrap up refactoring/editing Scheme code
- Make my code compliant with the music notation rules set by Elaine
Gould's *Behind Bars* textbook if needed
The notation rules should be implemented in the regression tests described
earlier.
- End of Week 6 (Jul 7)
- All necessary changes to scheme code should be done
- At least 50% of test cases/regression tests concerning beaming should pass
- Output should be consistent with music notation rules outlined in *Behind
Bars*
- Week 7 (Jul 10-Jul 14)
- Midterm Evaluations
- Consider issues branching from the main issue and whether my project will
be able to solve them on time
- Work on below if have time
- Weeks 7-9 (Jul 10-Jul 28)
- Write regression tests for the new capabilities my project brings (mostly
for regular note beaming, some for tuplet beaming)
- Work on rewriting documentation concerning beaming
- Perform necessary modifications to `convert-ly` rules
Adding new convert-ly rules is really important. Thanks for making this part
of your proposed work!
- Start working on tuplet beaming if have time
- End of Week 9 (Jul 28)
- Documentation concerning regular note beaming for developers and general
public should be finished
- Continuous integration tests with refactored code should pass
- `convert-ly` rules should be correctly working for regular note beaming
If you wrote your initial regression tests for the current syntax, they’d be a
great set of files for proving convert-ly rules.
- All test cases for regular note beaming should be finished
- Week 10-12 (Jul 31-Aug 18)
- Traveling/Moving during Week 12, so workload will be reduced during week
12
- Work on tuplet beaming
- Work on resolving as many GitLab issues related to regular note beaming
- Add more test cases/regression tests, documentation explanations, etc.
- End of Week 12 (Aug 18)
- Tuplet beaming should be mostly correct
I haven’t seen when you started working on Tuplet beaming – ( I guess you said
week 9 if you have time). I wonder if weeks 10-12 will be enough time to get
tuplet beaming fixed.
It would be hard to apply your changes if they made tuplet beaming worse. But
we could certainly apply your changes if they didn’t harm current behavior
(tuplet beams generally work, but subdividisions do not).
- May not be able to pass test cases/regression tests that strain
tuplet beaming capabilities
- Its `convert-ly` rule should be correct at least
- Week 13 (Aug 21-25)
- My university term starts this week, reduced work
- Assess remaining work that the project cannot finish on time
- Write additional code comments/documentation/reg test ideas for work
to be finished in the future
Do you or any other developers have any thoughts and feedback on the
feasibility or structure of my plan? Its a large 350 hour project to be done in
10 full-time weeks (about 30-32 hrs/wk) and 3 part-time weeks (about 10-20
hrs/wk). Plan's start/end dates align with Google's timeline for GSoC.
I appreciate any feedback and support you can give me!
I like your plan!
--
- Jason Yip
