Hi all,
I'm writing an assessment how the beaming-pattern code could be redone
properly, which is pretty much necessary. Apart from some minor problems
at the surface at least the concept of (subdivide the) beaming of
tuplets it completely messed up. In fact, beam subdivision is simply
unusable as soon as tuplets are involved. About two years ago I tried to
work on this but didn't complete the task, and re-reading the code and
recalling what I have probably tried back then I realize that I had
continued in the tradition of adding patches on top of patches. Whenever
I noticed unintended behaviour I tried to find the cause and fix that.
Instead I think it's necessary to rethink the topic from the ground up.
I suggest to rewrite beaming-pattern.cc from scratch and check at each
step which existing code can be reused. In order to be able to do that
I'm right now figuring out the mechanics of beam subdivisions and
everything else related to beaming-pattern in order to come up with a
strategy that will allow an implementation that starts from the best
possible reference points and avoids special treatment of special cases
as much as possible. I'm sure I will have a number of questions about
this (and this post will be the first).
I'm not sure if I will ever manage to do that coding work. If I'll do I
will definitely need help because I will fail if I have to find all the
pieces of information I need through "git grep" on my own. Ideally this
should be team/pair work from the start.
However, if I won't work on it myself I want to at least have this
documentation ready, hoping for someone else to pick this up. It's not
one of the most important aspects of engraving, but definitely one where
LilylPond currently actually isn't usable. Actually the trigger for
thinking about this was that I noticed that Dorico has one identical bug
to LilyPond. When I reported that to Daniel Spreadbury I got the feeling
that it would be really great if we would fix that before Dorico ;-) But
while fixing this specific issue would probably be a breeze (as the
wrong behaviour is introduced on purpose due to a misunderstanding) I
think it really should be done properly this time.
So, now the first question ...
The terminology of baseMoment, beats and groups is inconsistent between
the NR
(http://lilypond.org/doc/v2.19/Documentation/notation/beams#setting-automatic-beam-behavior)
and the code. The question is, what are the components of the following:
\set baseMoment = #(ly:make-moment 1/8)
\set beatStructure = 3,3,2
From the text in the NR this would be three beats, divided in three or
two base moments each.
However, the C++ code (and the code comments) refer(s) to that as three
groups with three beats each.
If my conclusion is correct I suggest to change the naming in the code
because that reflects musical reality more naturally, IMHO.
In a way this is a superficial question, but I need to fully understand
both the underlying concepts and the existing code:
- what is sloppy (may be the case here)
- what is conceptually wrong in the code
- what is correct and I just haven't understood yet
Best
Urs
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
