> What I meant is that I do believe that it is impossible to
> mechanically translate an old score to give exactly the same result
> with the new code.
`Exactly the same' should not be the goal IMHO – we have to freeze the
sources (similar to TeX) to achieve that. The output should rather be
`reasonable'.
> We do not need "__", so eliminate it: sed -e "s/__//g"
>
> Ok, that looks good. But wait: There is a melisma, and it would be
> longer than minimum-length, the new engraver adds an extender line.
> But there is no "__", so the old code did not engrave an extender
> line. Ok, add an override to be sure there is no extender with the
> new code. Is convert.ly intelligent enough to handle that problem
> correctly? I doubt that although I admit that I never had a look at
> the code.
Well, we had similar, incompatible updates already. The usual route
was to make `convert-ly' try the best and emit a message
Not smart enough to convert foo.
Please refer to the manual for details, and update manually.
Werner
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
