Re: Strange beaming error

[Urs Liska]

Am 07.01.2016 um 10:16 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Do you also have subdivideBeams = ##t somewhere?
>> If so please show the result with both 2.19.28 and .35..
>>
>> And if that's the case you should maybe send me (privately?) the full
>> piece so I could test with several builds before and after several
>> recent changes.
> It's not the first time the subdivision fixes had to be overhauled.  And
> if we keep up the way of dealing with them, I rather doubt it will be
> the last time.

Maybe I should clarify something about this history.

Beam subdivision wasn't ever correct in so far that at any subdivision
(only) one beam was left, and I reported this as a bug last April.
As issue 4355 this was fixed (not by me).

In November I noticed a new issue and realized it was an unnoticed side
effect of 4355.
I fixed this as issue 4664, only to notice that the behavior introduced
in 4355 didn't work anymore.

As it turned out this wasn't my fault in 4664, but a few weeks after
4355 the behavior had been partially reverted (in
0382ed88b53cb24e76a1935e18df32cc87174428 "Adjust beam subdivision to
only occur at baseMoment", without further explanation and seemingly
without a tracker item.

So I gave the issue more thought and hoped to fix the issue properly.

>
> I suggest that you write down the rules, _all_ rules, that are supposed
> to be governing subdivision.  On paper.  As a simple recipe of the "if
> this condition is met, do this, else if that condition is met, do that,
> else ... otherwise ..." kind.

Basically this is what I did, but there were cases I couldn't imagine.
One of them is when baseMoment equals the actual note duration.

The obvious issue of the OP was a case where this is actually improper
LilyPond coding:

\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/16)
c16 c c c

just makes no sense. And this is why I didn't give that case more thought.
But with

\set subdivideBeams = ##t
\set baseMoment = #(ly:make-moment 1/16)
c16 c c64 c c c c32 c

It *does* make sense to have beam subdivision points at every note (the
first three ones).

The other case that deserves further attention is when the beam is
shortened, but not at the end but at the beginning (i.e. r32 c c c).

So I think I'll follow your suggestions above and below, considering
these cases and do my best to identify other (corner) cases.

>
> _Then_ you check the examples making problems.  On paper.  Does LilyPond
> follow the rules?  If so, the rules may need changing.  Where the rules
> cannot sensibly changed to accommodate conflicting but equally valid
> cases, we'll have to introduce manual intervention methods that are to
> be used for a well-defined and humanly recognizable subset of cases.
>
> If LilyPond does _not_ follow the rules on paper however, the
> implementation is broken.  How did it manage to escape scrutiny several
> times?  Perhaps a rewrite is required where the logic of the code can
> trace the human-accessible rules so closely that there is no doubt about
> the code matching the rules.
>
> Oh, and that paper with the rules?  Once the code follows it, the
> content of the paper belongs in code comments and possibly a manual.

Well, I think I have covered *most* rules, and these are documented
pretty extensively in the code comments and the regtests.

Urs

>