Valentin, Thanks for this. It is always interesting to see how others get along with this task.
On Mon, Jan 20, 2014 at 1:36 AM, Valentin Villenave <valen...@villenave.net>wrote: > [ snip ] > - 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. > Sometimes I find the gyrations I have to go through with converting "markup dynamics" to be really daunting. It depends on time invested so far and the size and complexity of the piece. > - 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. > Agreed on the fair game. I make use of GIT by doing a fairly minimalist, make-it-work-and-review, pass and commit that in a local branch. Then I can feel free to do more in-depth conversions that involve wholesale removal of old position tweaks, manual breaks, etc. - 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). > I haven't done anything quite that radical. I agree with your particular instance, however, where there are not many voices. I have recently committed a Mozart update (KV315) from LilyPond 1.5.x where several files were deprecated simply because they were cut & paste of other files to get, for example, 2 horns into a part score. With very few edits the partcombine tool worked perfectly and I even uncovered an error during review. (For the age of the LilyPond version it went extremely well; way faster than the time I took reviewing.) > - 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. > I know everybody has their editor preference but I wouldn't be nearly as efficient in updating without emacs, especially with point-and-click from the PDF viewer. I have a habit of removing trailing whitespace and that typically creates many additional diffs. And if my problem is reading LilyPond I'll just give up and re-indent the entire thing, understanding that it is tough on volunteer reviewers. [ Thanks, DK, for the mention of "recode" as a tool for UTF-8 updates. I've now got the tool but haven't taken it for a spin yet. ]
_______________________________________________ Mutopia-discuss mailing list Mutopia-discuss@mutopiaproject.org http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
