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.
- Similarly, one has to remind that basic markups were used for
practically everything, so you might want to double-check for
dynamics, \tempo indications, etc.
- 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'
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.
- 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.
- Original comments may be left alone; unnecessary hacks may be
commented out rather than deleted, just in case. (Except for the whole
Ottava workaround above, which I’ll gladly delete with a vengeance.) I
try to document what I do as much as possible, since I very much hope
someone (other than me!) will be there to update the code again in
another dozen years.
- I took the liberty of concating the whole thing a single, 3000+ LOC
file, rather than the original structure with no less than fifteen
files. Working with a single file is much, much easier in my opinion
(particularly when it’s a single-instrument piece).
- Handling such files is when you realize how much coding style
quality does matter. Apart from the prehistoric weirdness of ancient
people (I can’t bear to look at the way I wrote code in 2006), do keep
in mind that there were less user-friendly editors back then. It may
not matter for small scores, but for large scores where you can’t
reasonably expect to come up with a proper diff showing just a dozen
differences, you may want to reindent the whole text input, remove
unnecessay newlines and reinsert your own newlines after every brace,
every barcheck etc. Frescobaldi’s or LilyPondTool’s regexp
search-and-replace, and auto-indenting functions, will be of great
help in this regard.
Cheers,
Valentin.
___
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
