Re: gap(s) in versions for convert-ly
Kieran Coulter wrote: Hello again, I found the piece and version number in question, it's the 4th ballade by Chopin, and convert-ly gets it up to version 2.5.18 before it can't get any further. Am I right in assuming that the last line in the log file is the one that prevents the file rendering? You should read the log output from convert-ly, which says: Not smart enough to convert auto beam settings Auto beam settings must now specify each interesting moment in a measure explicitely; 1/4 is no longer multiplied to cover moments 1/2 and 3/4 too. Please refer to the manual for details, and update manually. What you should do in this particular case is to replace the line (which appears twice in the file) \override Staff.autoBeamSettings #'(end 1 24 6 8) = #(ly:make-moment 3 24) with the following lines: #(override-auto-beam-setting '(end 1 24 6 8) 3 24 'Staff) #(override-auto-beam-setting '(end 1 24 6 8) 6 24 'Staff) #(override-auto-beam-setting '(end 1 24 6 8) 9 24 'Staff) #(override-auto-beam-setting '(end 1 24 6 8) 12 24 'Staff) #(override-auto-beam-setting '(end 1 24 6 8) 15 24 'Staff) and similarly to replace the line #(override-auto-beam-setting '(end 1 24 6 8) 3 24 ) with the following lines: #(override-auto-beam-setting '(end 1 24 6 8) 3 24) #(override-auto-beam-setting '(end 1 24 6 8) 6 24) #(override-auto-beam-setting '(end 1 24 6 8) 9 24) #(override-auto-beam-setting '(end 1 24 6 8) 12 24) #(override-auto-beam-setting '(end 1 24 6 8) 15 24) Once you have done that, you go to the top of the file and replace \version 2.5.18 by \version 2.5.21 to tell convert-ly that you have manually handled that conversion. Now, you can run convert-ly again to update the file from 2.5.21 to your current version. If you again look at the log output from convert-ly, you will notice that it says (among others) Not smart enough to convert space-function and Span_dynamic_performer has been merged into Dynamic_performer To handle the latter message, just remove the line \consists Span_dynamic_performer Regarding the space-function, I would simply start by trying to comment out the lines that override the space-function property and compare the corresponding bars of the output with the PDF file in Mutopia to see if it's worth spending time to find a corresponding tweak or of LilyPond has improved so that the tweak is no more necessary. Now, that you run the file through LilyPond, you will hopefully not get any serious error messages (at least I don't when I try it here). However, you will notice that the output isn't entirely perfect and that LilyPond spits out a number of warning messages, that may be worth investigating. In other words, convert-ly cannot handle everything. For example, you may want to fix the following: - The più f indications are wrong. When the original .ly file was written, you had to use LaTeX commands to get this accented character, now you should instead input the character directly in your editor and save the file in UTF-8 encoding. Fortunately, these indications are defined as macros at the top of the .ly file, so you only have to make the change in these macro definitions instead of having to search through the full file. - Bar 134 has some very funny looking slurs for the acciaccaturas. If you look in the .ly file, you will notice that the original editor has included a number of extra tweaks to handle some layout problem in LilyPond version 2.1.0. Again, I propose to simply comment out all these extra \overrides first and see if you get an acceptable output. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: gap(s) in versions for convert-ly
As you have noticed, there are a few constructs that convert-ly isn't smart enough to handle automatically. These happen for a number of LilyPond versions, but this doesn't mean that convert-ly isn't able to handle any scores that are older than so, it just means that convert-ly fails to handle the small percentage of scores that happened to use that particular feature. Also, it's often very easy to do the corresponding changes manually, so there's no reason to dump the file even if convert-ly can't handle all the conversion steps automatically. The typical procedure is: 1. Figure out from the convert-ly error message at which LilyPond version the problem appears, let's say in the conversion to version 2.5.18. 2. Run convert-ly up to the version number before the problem appears: convert-ly --to=2.5.17 myfile.ly 3. Manually update the file and manually update the version number in the file by one step (i.e. to 2.5.18 in this case) 4. use convert-ly to upgrade the file to the current version. Of course, step 3 may require some detective work. The good news is that many of the more obscure constructs in .ly files that convert-ly can have a problem with, were originally introduced in order to handle some bug or shortcoming in that particular LilyPond version and there's a good chance that the lines can simply be removed. Also, if you get stuck figuring out what to do with the file, just send an email to the mailing list and there's a good chance that someone can assist. /Mats Kieran Coulter wrote: Hello, I was wondering, upon attempting to update .ly scripts from Mutopia that had various original version #s, is there a few version gaps that make .ly files written using a certain version or earlier obsolete, meaning they can't be updated all the way to the current version? I noticed one around either 1.5 or 2.5, I forget which, that said not smart enough to update autobeam settings or something like that. Anyways, I am just trying to see at what version or earlier a file has to be for me to know that I shouldn't bother working on modifying it if it can't produce an output. Also, if there is a workaround for this gap, or any other gaps I am not yet aware of, please let me know! Thanks! ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: gap(s) in versions for convert-ly
Hello again, I found the piece and version number in question, it's the 4th ballade by Chopin, and convert-ly gets it up to version 2.5.18 before it can't get any further. Am I right in assuming that the last line in the log file is the one that prevents the file rendering? If so, the the line in question is error: unknown translator: 'span_dynamic_performer' Here is the entire log: -compilation-*- Changing working directory to `J:/Mutopia Piano Database/Chopin/Ballades' Processing `J:/Mutopia Piano Database/Chopin/Ballades/ballade-4.ly' Parsing... error: Incorrect lilypond version: 2.5.18 (2.7.38, 2.10.20) error: Consider updating the input with the convert-ly script error: unknown translator: `Span_dynamic_performer' I tried simply removing that log, but then I get a win32 exception that triggers my Visual Studio debugger, so it doesn't seem to work. What can I use to manually update the file so I can convert it all the way to 2.10.20? And after I do the manual adjustment, would I then manually update the version number to 2.5.19? Thanks so much for the assistance. --- Original Message Follows --- From: Mats Bengtsson To: Kieran Coulter Cc: Subject: Re: gap(s) in versions for convert-ly Date: Wed, 18 Apr 2007 08:39:53 +0200 As you have noticed, there are a few constructs that convert-ly isn't smart enough to handle automatically. These happen for a number of LilyPond versions, but this doesn't mean that convert-ly isn't able to handle any scores that are older than so, it just means that convert-ly fails to handle the small percentage of scores that happened to use that particular feature. Also, it's often very easy to do the corresponding changes manually, so there's no reason to dump the file even if convert-ly can't handle all the conversion steps automatically. The typical procedure is: 1. Figure out from the convert-ly error message at which LilyPond version the problem appears, let's say in the conversion to version 2.5.18. 2. Run convert-ly up to the version number before the problem appears: convert-ly --to=2.5.17 myfile.ly 3. Manually update the file and manually update the version number in the file by one step (i.e. to 2.5.18 in this case) 4. use convert-ly to upgrade the file to the current version. Of course, step 3 may require some detective work. The good news is that many of the more obscure constructs in .ly files that convert-ly can have a problem with, were originally introduced in order to handle some bug or shortcoming in that particular LilyPond version and there's a good chance that the lines can simply be removed. Also, if you get stuck figuring out what to do with the file, just send an email to the mailing list and there's a good chance that someone can assist. /Mats Kieran Coulter wrote: Hello, I was wondering, upon attempting to update .ly scripts from Mutopia that had various original version #s, is there a few version gaps that make .ly files written using a certain version or earlier obsolete, meaning they can't be updated all the way to the current version? I noticed one around either 1.5 or 2.5, I forget which, that said not smart enough to update autobeam settings or something like that. Anyways, I am just trying to see at what version or earlier a file has to be for me to know that I shouldn't bother working on modifying it if it can't produce an output. Also, if there is a workaround for this gap, or any other gaps I am not yet aware of, please let me know! Thanks! ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
gap(s) in versions for convert-ly
Hello,I was wondering, upon attempting to update .ly scripts from Mutopia that had various original version #s, is there a few version gaps that make .ly files written using a certain version or earlier "obsolete", meaning they can't be updated all the way to the current version?I noticed one around either 1.5 or 2.5, I forget which, that said "not smart enough to update autobeam settings" or something like that. Anyways, I am just trying to see at what version or earlier a file has to be for me to know that I shouldn't bother working on modifying it if it can't produce an output.Also, if there is a workaround for this gap, or any other gaps I am not yet aware of, please let me know!Thanks!___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: gap(s) in versions for convert-ly
Kieran Coulter wrote: I was wondering, upon attempting to update .ly scripts from Mutopia that had various original version #s, is there a few version gaps that make .ly files written using a certain version or earlier obsolete, meaning they can't be updated all the way to the current version? In theory anything from 2.0 can be updated to 2.10. Anything written in 1.x will probably require manual coding. In practice, files in 2.0 and up that were written badly may require manual coding as well. Also, if there is a workaround for this gap, or any other gaps I am not yet aware of, please let me know! I trust that you've read the sections in the documentation that discuss convert-ly, so nothing else. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
