Valentin Villenave <valen...@villenave.net>
writes:
> Greetings everybody,
> I just sent Glen an update for Liszt’s second Ballad (mutopia 236).
> There was quite a bit of work involved, so I thought I’d share some
> of the hiccups here (feel free to expand or comment):
>
> - Apparently in 2002-2003 there wasn’t any support for OttavaBrackets
> and the like (I know! Right?). So, any octaviation (which is fairly
> standard in piano music) involved at least a dozen lines of code, an
> additional invisible voice with hardcoded invisible high notes, a
> customized text spanner, resetting the middleCPosition, etc. Ugly,
> ugly, ugly. There’s hardly any automated way of cleaning these things,
> but it does feel very rewarding to remove the whole thing by hand and
> replace it with a neat \ottava command.
That's actually an incentive to get common functionality into LilyPond
with a sustainable syntax, never mind how bad it works: it can be
improved later on anyway, and throwing out positioning tweaks on a hunch
is easier to do than substituting complex code.
See also:
> - Back then, LilyPond did a very bad job at avoiding collisions and
> there often was a need for since-then-long-forgotten hackish
> workarounds; therefore quite a lot of the oddities one may encounter
> in ancient code may now be safely removed altogether. (Even when it
> comes to manual \break points.) To be honest, there will be a few
> cases where you’ll just want to give up and leave these alone (for
> example ugly multiple voices that issue collision warnings when
> compiling). As long as it’s harmless enough, doesn’t cause weird
> output and won’t prevent future syntax updates, I think it’s fair
> game.
> - convert-ly is quite good, but it has a few weak spots. Particularly
> when handling the huge change in chords prior to version 1.8 (look for
> 1.7.28 in convert rules), where durations and stuff (dynamics,
> markups, articulation marks) were no longer put _inside_ chord
> constructs but immediately after.
> Sometimes convert-ly may get confused, for example with such things as
>
> <a'8^\markup { blabla } _^-| ^> \f c' e'>
convert-ly is not cast in stone even regarding prehistoric versions. If
you encounter weak spots on a regular basis, it might make sense
reporting them. There is no reason for convert-ly 2.19.6 not to be
better than convert-ly 2.19.5 at converting version 1.7.27 syntax to
1.7.28. _Iff_ it still sees regular action.
> Therefore, one should always double-check for articulation marks etc.
> Similarly, convert-ly may leave you with weird slurs and manual beams
> (since the syntax was _very_ different back then, see
> http://lilypond.org/doc/v1.6/Documentation/user/out-www/lilypond/Slurs.html#Slurs)
> so remember to look for empty ( ) or ) ( or [ ] constructs.
( ) [ ] are nowadays redefinable. It would be possible to redefine the
syntax to the old style ad-hoc instead of converting, when it's really,
really important. On the other hand, that makes the document badly
maintainable in future.
> - Among the things convert-ly will not do for you, back then the only
> way to input accented characters in LilyPond was the TeX way : e.g.
> "pi\`u forte". One has to track these down and replace them with
> proper UTF8 chars, otherwise the result is quite ugly in the score.
Again, it would appear that if those characters are a recurring problem
that one might want to see whether convert-ly can be improved.
But possibly it would make sense to just call recode tex..utf-8 on the
file manually and see where this gets one.
--
David Kastrup
_______________________________________________
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
