Re: Strange beaming error

[Urs Liska]

Am 7. Januar 2016 10:16:29 MEZ, schrieb David Kastrup <address@hidden>:
>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.
>
>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.
>
>_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.


Before testing further I assume the current issue is due to *not* using the 
latest state (which isn't in a release yet).

But of course I'll test with the material and with all iterations of the code 
once I have it.

Urs
-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.