Urs Liska <u...@openlilylib.org> 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. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
