Re: ScholarLY - introduction and call for collaboration
Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of
Re: ScholarLY - introduction and call for collaboration
Am 03.02.2015 um 01:55 schrieb Craig Dabelstein: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had: \include ../Notes/flute.ily \include part-init.ily I reversed the order of these two lines and now it works perfectly. \include part-init.ily \include ../Notes/flute.ily Ah yes, I did that too, but thought I needed that only for the dynamics-def file... It is still producing an inp file for every single part though. I'm not sure what you mean. As it is the function will produce one .inp file for any compilation. So if you compile a part it will produce a file for that part, and if you compile the score it will compile a file with annotations for the whole score. If that's not what you want (which is quite normal) you have to control the behaviour with the configuration commands (and that's where the multipart include set-up comes in). Try putting \setAnnotationExportTargets #'(latex) in init-score.ily and \setAnnotationExportTargets #'() in init-part.ily (and remove that command from init-main.ily) HTH Urs Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com wrote: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com
Re: ScholarLY - introduction and call for collaboration
Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com mailto:craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can
Re: ScholarLY - introduction and call for collaboration
Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had: \include ../Notes/flute.ily \include part-init.ily I reversed the order of these two lines and now it works perfectly. \include part-init.ily \include ../Notes/flute.ily It is still producing an inp file for every single part though. Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include
Re: ScholarLY - introduction and call for collaboration
It is now working ABSOLUTELY BRILLIANTLY! Thanks for all your help. Craig On Tue Feb 03 2015 at 11:15:18 AM Urs Liska u...@openlilylib.org wrote: Am 03.02.2015 um 01:55 schrieb Craig Dabelstein: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had: \include ../Notes/flute.ily \include part-init.ily I reversed the order of these two lines and now it works perfectly. \include part-init.ily \include ../Notes/flute.ily Ah yes, I did that too, but thought I needed that only for the dynamics-def file... It is still producing an inp file for every single part though. I'm not sure what you mean. As it is the function will produce one .inp file for any compilation. So if you compile a part it will produce a file for that part, and if you compile the score it will compile a file with annotations for the whole score. If that's not what you want (which is quite normal) you have to control the behaviour with the configuration commands (and that's where the multipart include set-up comes in). Try putting \setAnnotationExportTargets #'(latex) in init-score.ily and \setAnnotationExportTargets #'() in init-part.ily (and remove that command from init-main.ily) HTH Urs Craig On Tue Feb 03 2015 at 10:54:36 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Dear Urs, Thanks so much for your advice. I tried both methods you suggest and neither one worked, but this did ... Originally I had \include part-init.ily \include ../Notes/flute.ily On Tue Feb 03 2015 at 9:51:03 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, it's like I expected (and not related to \anntoate): Am 03.02.2015 um 00:00 schrieb Craig Dabelstein: Hi Urs, Here is a zip of the complete project. There are 2 issues: [1] If I put part-init.ily and score-init.ily in the top-most folder (the same folder as main-init.ily), lilypond returns an error -- cannot find main-init-ily. There are two ways how LilyPond treats include paths, relative and non-relative. By default LilyPond looks for \include files - in a path relative to the location of the *compiled* file - in a path relative to the include path (you'll get that from the error message) Therefore: When you have \include ../score-init.ily and in that file you write \include main-init.ily LilyPond will look for that file in the directory of the compiled file and not in that of score-init.ily. There are two solutions to your problem: a) exchange the second include for \include ../main-init.ily b) enter #(ly:set-option 'relative-includes #t) at the beginning of score-init.ily. This will make LilyPond look in paths relative to the file where \include is used. I suggest solution b) because that is usually more versatile for complex include cascades. (BTW I thought this was default behaviour by now ???) [2] With the annotate file included in the main-init.ily file, the score engraves perfectly (and produces the inp file), but the parts won't engrave at all and return errors as they can't find the annotate file. This is a follow-up of the first issue, if main-init.ily isn't found then (of course) the annotate include in that file isn't done too. So this should now be solved automatically. Hope it works now. Best Urs Many thanks, Craig On Tue Feb 03 2015 at 4:37:44 AM Urs Liska u...@openlilylib.org wrote: Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at
Re: ScholarLY - introduction and call for collaboration
Am 31.01.2015 um 18:23 schrieb Urs Liska: Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig Sorry, forgot about this. Could you please send me your _exact_ directory structure?. Including being completely accurate about dots and hyphens? Urs I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list
Re: ScholarLY - introduction and call for collaboration
Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig I may look into it in a few hours. Maybe a case for a tutorial ... On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Urs, Another question ... Is there a reason why main.init.ily, part-init.ily and score-init.ily can't be in the same folder? If I put part and score in a sub folder they can locate main in the folder above, however, if I put them all in the same folder I get cannot find file main-init.ily errors. Strange! Craig On Sun Feb 01 2015 at 3:11:35 AM Craig Dabelstein craig.dabelst...@gmail.com wrote: Hi Urs, I followed your advice re: file structure -- main-init.ily has annotate, and part.init.ily and score-init.ily include main.init.ily. When engraving the score it all works perfectly, but when engraving a part, it gives errors because it can't find annotate. Any ideas? Craig On Sat Jan 31 2015 at 4:58:58 PM Urs Liska u...@openlilylib.org wrote: Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Rep: ScholarLY - introduction and call for collaboration
It turns out that custom annotation types were not properly handled.
\annotate looks up the LaTeX value in an alist dictionary, and for custom
annotations this simply returned #f.
Pushed a fix, should work now.
Thanks for the report.
Best
Urs
Thanks :-)
I still have an issue on the example file, on the custom annotation, with this
message:
./annotate.annotations.inp:15: Undefined control sequence.
argument See \textbackslash what is \possible
[opts]{args}
l.15 {custom-annotation}
Something else I noted: the lilypond code in the custom annotation is
transformed into a LilyPond Music tag in the .inp file. Is that normal?
Philippe
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Rep: ScholarLY - introduction and call for collaboration
Am 30.01.2015 um 21:50 schrieb Philippe Massart:
It turns out that custom annotation types were not properly handled.
\annotate looks up the LaTeX value in an alist dictionary, and for
custom annotations this simply returned #f.
Pushed a fix, should work now.
Thanks for the report.
Best
Urs
Thanks :-)
I still have an issue on the example file, on the custom annotation,
with this message:
./annotate.annotations.inp:15: Undefined control sequence.
argument See \textbackslash what is \possible
[opts]{args}
l.15 {custom-annotation}
OK, this is stupid.
I used that example property to show what is possible in that LaTeX
code is exported verbatim. But I didn't think about the fact that this
example code is nonsense. Of course \possible is an Undefined control
sequence ...
I think I should have given that example document slightly more care ...
I've updated to a more straightforward command. Thank you for reporting.
Something else I noted: the lilypond code in the custom annotation is
transformed into a LilyPond Music tag in the .inp file. Is that normal?
I don't know if that's the ultimate solution but it's intended. As I
wrote the properties can digest any single Scheme/LilyPond expression
including music. But if I wouldn't alter it the whole Scheme
representation would be printed, and that is something one generally
wouldn't want to do. There will have to be some ways to produce actual
*music* from it (i.e. an engraved score fragment) but for now I think
this is the best compromise. (For time signatures I managed to intercept
them and print a meaningful result, but the other music types just were
too complex for that.
Best
Urs
Philippe
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Rep: ScholarLY - introduction and call for collaboration
I still have an issue on the example file, on the custom annotation, with
this message:
./annotate.annotations.inp:15: Undefined control sequence.
argument See \textbackslash what is \possible
[opts]{args}
l.15 {custom-annotation}
OK, this is stupid.
I used that example property to show what is possible in that LaTeX code is
exported verbatim. But I didn't think about the fact that this example code
is nonsense. Of course \possible is an Undefined control sequence ...
I think I should have given that example document slightly more care ...
I've updated to a more straightforward command. Thank you for reporting.
Something else I noted: the lilypond code in the custom annotation is
transformed into a LilyPond Music tag in the .inp file. Is that normal?
I don't know if that's the ultimate solution but it's intended. As I wrote
the properties can digest any single Scheme/LilyPond expression including
music. But if I wouldn't alter it the whole Scheme representation would be
printed, and that is something one generally wouldn't want to do. There will
have to be some ways to produce actual *music* from it (i.e. an engraved
score fragment) but for now I think this is the best compromise. (For time
signatures I managed to intercept them and print a meaningful result, but the
other music types just were too complex for that.
Best
Urs
Thanks, it’s clearer now :-)
And yes, « actual » music will be another interesting step.
In a few month, a friend of mine will work on a critical edition; I plan to use
that work to make a LaTeX + LilyPond version and test ScholarLY.
Philippe___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org mailto:lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Thanks Urs, And you put the \include annotate code in the main-init.ily file? Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein craig.dabelst...@gmail.com: Thanks Urs, And you put the \include annotate code in the main-init.ily file? Yes, and any similar code like the include of global-defs.ily etc. too. Urs Craig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska u...@openlilylib.org wrote: Hi Craig, Am 30.01.2015 um 17:59 schrieb Craig Dabelstein: Urs, Here is a zip of the complete project. Thank you, this was indeed instructive (and a nice score BTW). There is an issue with your set-up which I had immediately noticed and wanted to tell you about, even before I realized you had a problem with the annotations. I thought this would be only a matter of clean coding but somehow this triggered your issue. Each annotation is generated multiple times - once for each time you included annotate.ily. So you should only include it once, which is what I would have recommended anyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes that apply for any file in the project. Two files like score-init.ily and part-init.ily. These include main-init.ily and add specific settings to score or part compilation The score file includes score-init.ily and each part file includes part-init.ily This way everything is only included once, and can also be modified in one single place. ### However, this is only a case of sloppy coding and shouldn't have such consequences, so I'll have to sort it out on my side. It seems each time you include annotate.ily you create a new instance of the engraver. I had thought that re-including a file would simply be re-defining everything and be a waste of resources. But obviously when you do \consist something multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) are redefined so later includes simply overwrite the earlier ones. But as the engraver is consisted in the Staff context multiple times it is also executed multiple times. If you carefully inspect the console output you will notice that the output file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so in a first run annotations are appended to this list and in a second run they are finally written out. (This is done to have a list that can be sorted before outputting). This seems to result in all instances of the engraver adding their copy of an annotation to the list so not only the output file is generated N times but each annotation is produced N times. As said above the result is a harsh indicator of improper project structure but the module should be able to handle that gracefully. I will think about if I just suppress multiple includes or if I find a better way to structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Hi Urs, I put \include scholarly/annotate.ily in each of my 24 files -- one for each instrument. In the score I put: \include scholarly/annotate.ily \setAnnotationExportTargets #'(plaintext latex) I added 1 criticalremark and 1 musical issue to test it out. The generated parts (both the log and the inp) are printing each of the issues 25 times. See inp file attached. Craig On Fri Jan 30 2015 at 5:16:33 PM Urs Liska u...@openlilylib.org wrote: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs Philippe ___ lilypond-user mailing listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user Mendelssohn-01-score.annotations.inp Description: Binary data ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 30.01.2015 um 09:35 schrieb Craig Dabelstein: Hi Urs, I put \include scholarly/annotate.ily in each of my 24 files -- one for each instrument. In the score I put: \include scholarly/annotate.ily \setAnnotationExportTargets #'(plaintext latex) I added 1 criticalremark and 1 musical issue to test it out. The generated parts (both the log and the inp) are printing each of the issues 25 times. See inp file attached. Could you please also send the LilyPond files (or at least a few of the part files and the score)? Urs Craig On Fri Jan 30 2015 at 5:16:33 PM Urs Liska u...@openlilylib.org mailto:u...@openlilylib.org wrote: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs Philippe ___ lilypond-user mailing list lilypond-user@gnu.org mailto:lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org mailto:lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 30.01.2015 um 08:16 schrieb Urs Liska: Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs It turns out that custom annotation types were not properly handled. \annotate looks up the LaTeX value in an alist dictionary, and for custom annotations this simply returned #f. Pushed a fix, should work now. Thanks for the report. Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Dear Urs, I incorporated annotate into one of my current scores and it is fantastic. I can't wait for the Latex package to go along with it. Thanks for all you hard work. Craig On Wed Jan 28 2015 at 8:35:07 PM Noeck noeck.marb...@gmx.de wrote: I hope my other reply is a sufficient answer to this? Yes, of course (and I agree). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Dear Craig, thank you for the report. Am 30.01.2015 um 03:28 schrieb Craig Dabelstein: Dear Urs, I incorporated annotate into one of my current scores and it is fantastic. Great. Just to let me know: did you experience any troubles or is it as simple as I think to get it to run? I can't wait for the Latex package to go along with it. There is already a very basic stub in the /tex directory. You can try that out, simply use it in a document and \input the generated .inp file(s). Best Urs Thanks for all you hard work. Craig On Wed Jan 28 2015 at 8:35:07 PM Noeck noeck.marb...@gmx.de mailto:noeck.marb...@gmx.de wrote: I hope my other reply is a sufficient answer to this? Yes, of course (and I agree). ___ lilypond-user mailing list lilypond-user@gnu.org mailto:lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Hello, I’ tried the LaTeX package. Annotations are well included and it looks promising. But the beginning of the file causes an error due to the sharp symbol in the first part of the file (the part before the \musicalissue ) Error: (./annotate.annotations.inp ./annotate.annotations.inp:1: You can't use `macro parameter character #' in ve rtical mode. Result: Is there something I did wrong? Philippe___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 30.01.2015 um 08:07 schrieb Philippe Massart: Hello, I’ tried the LaTeX package. Annotations are well included and it looks promising. But the beginning of the file causes an error due to the sharp symbol in the first part of the file (the part before the \musicalissue ) Error: (./annotate.annotations.inp ./annotate.annotations.inp:1: You can't use `macro parameter character #' in ve rtical mode. Result: Is there something I did wrong? Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs Philippe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : annotate.annotations.inp Description: Binary data annotate.ly Description: Binary data Philippe___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 30.01.2015 um 08:13 schrieb Philippe Massart: Probably not. I assume that hash hasn't been properly filtered. Could you please post the generated .inp and maybe also the LilyPond file? Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into the reason why this is generated. The #f in the first line of the .inp file is the result of exporting something that evaluates to false. Urs Philippe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Dear Urs, Bravo! This is excellent work. I really appreciate all the time and effort you put into Lilypond. Craig maximesmusic.com On Wed Jan 28 2015 at 9:58:13 AM tyronicus samuelsp...@gmail.com wrote: I must immediately excuse myself for not reading the blog post first and seeing that ScholarLY is a part of openlilylib. But I still wonder about the rest. -- View this message in context: http://lilypond.1069038.n5. nabble.com/ScholarLY-introduction-and-call-for- collaboration-tp171140p171152.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
why we use so many discrete projects and repositories I would like to second this. I am much more likely to check things out (and perhaps contribute to things) that are in the openlilylib snippets as this is the only repo I have checked out besides the lilypond git. All other repos would be an extra step and need extra motivation to do so. But of course you are free to organize GASP etc. however you want. Thanks for the blog post and the work behind it. From Urs’ questions on this list, I guess that the second last post on the blog was not the last one on partial compiling – which I find very exciting. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Hi Samuel, thanks for your thoughts. They are not offending at all but express valid concerns. However, I think there are good reasons to go the way I (and others) are going. All these things have to be seen in the context of an idea/project you can't know yet - specifications for a common library infrastructure. Libraries are a good way to extend LilyPond without having to add functionality to LilyPond itself. And I think everybody who reaches a certain productivity level will have his/her own library or libraries of some sort. Basically openLilyLib emerged from the wish to make such a personal library publicly available. However, by now openlilylib is a rather unstructured mass of code and not much more than an arbitrary _collection_ of snippets. The main difference to the official LSR is that openlilylib is _includable_ while you have to _copy_ snippets from the LSR and integrate it with your own files. In a way this is good because it is suitable for its original idea, namely to be a place where interesting code can be stored and made available. But it's already quite unwieldy to see what is actually in there, and this will definitely not become better when it grows more. So the idea is to reach a state where it is possible to create libraries in a consistent way and where it is very easy to install such libraries to make it available from LilyPond documents. This will make it possible to create libraries with specific missions (as you call it), for example scholarly editing, but also contemporary or ancient notation or whatever. In a way this should be similar to packages/modules for programming languages or a LaTeX distribution. There you will know (or get directed to) that when you are looking for functionality X you should have a look at module/package Y. This may also encourage people to contribute their tools to a given library instead of only setting up their private toolkits. One crucial part of that idea is creating a system of auto-generating documentation from the code files, also similar to how programming languages do it. Such a system will make the documentation and use of libraries much more convenient. One more idea is to also develop a kind of package manager that would make it easy to get selected packages. But this is not thought through at all yet. A compromise (which might actually be the perfect solution) could be to create one meta repository that _contains_ arbitrary libraries. That way one would only have to download/clone one repository and could access different libraries using some kind of namespace, e.g. \include oll/some/function.ily \include scholarly/annotate.ily I can see that all this activity still looks kind of scattered but the idea is to have a quite consistent and coherent environment in the not-to-distant future. Best Urs Am 28.01.2015 um 00:18 schrieb tyronicus: I am all in favor of the collaboration, but I wonder if I might pessimistically ask why we use so many discrete projects and repositories. It seems to me that we could accomplish much more by using one git project instead of having openlilylib, the LSR, and our newest projects, ScholarLY and GASP. On top of all these projects, I've noticed that a few LP users have their own repos of snippets and tools. Wouldn't the beginning to intermediate user of LilyPond be benefited by the ability to find all of these resources under one roof? Even the advanced user might more willingly contribute to the various projects if they were all right there in front of him/her. Assuming it is an idea of the different projects having separate 'missions,' why not broaden our horizons? I hope I haven't angered anyone who fills differently than I do. These are just the thoughts of an admitted beginner. -- View this message in context: http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171149.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
Am 28.01.2015 um 11:11 schrieb Noeck: why we use so many discrete projects and repositories I would like to second this. I am much more likely to check things out (and perhaps contribute to things) that are in the openlilylib snippets as this is the only repo I have checked out besides the lilypond git. All other repos would be an extra step and need extra motivation to do so. But of course you are free to organize GASP etc. however you want. I hope my other reply is a sufficient answer to this? Thanks for the blog post and the work behind it. From Urs’ questions on this list, I guess that the second last post on the blog was not the last one on partial compiling – which I find very exciting. Yep. I definitely want to reach the state where I can recompile the currently edited system only - which would dramatically increase the responsiveness of editing LilyPond files. Urs Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
I hope my other reply is a sufficient answer to this? Yes, of course (and I agree). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
I must immediately excuse myself for not reading the blog post first and seeing that ScholarLY is a part of openlilylib. But I still wonder about the rest. -- View this message in context: http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171152.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
ScholarLY - introduction and call for collaboration
Hi all, usually I don't advertise Scores of Beauty posts here, but every now and then there's an exception to the rule. I have just published a post introducing my new LilyPond library ScholarLY, which intends to become a powerful toolkit for scholarly edition workflows. The first building block that is in a usable state by now is \annotate, a set of functions to annotate musical content and to maintain annotations directly within the LilyPond input files. This can on the one hand _significantly_ increase efficiency in scholarly workflows, and on the other hand it can be used as a kind of in-source issue tracker for any kind of LilyPond project. I suggest anybody interested in scholarly editing having a look at the post at http://lilypondblog.org/2015/01/introducing-scholarly/ and consider joining the project. There is much more to be done, but also to be discussed and designed. So don't hesitate to come up with suggestions, questions and issues, even when you won't contribute a single line of code. Of course I have already had enormous benefits through the (Scheme) competence on this list. Many thanks to everybody, you'll know who I mean ... Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ScholarLY - introduction and call for collaboration
I am all in favor of the collaboration, but I wonder if I might pessimistically ask why we use so many discrete projects and repositories. It seems to me that we could accomplish much more by using one git project instead of having openlilylib, the LSR, and our newest projects, ScholarLY and GASP. On top of all these projects, I've noticed that a few LP users have their own repos of snippets and tools. Wouldn't the beginning to intermediate user of LilyPond be benefited by the ability to find all of these resources under one roof? Even the advanced user might more willingly contribute to the various projects if they were all right there in front of him/her. Assuming it is an idea of the different projects having separate 'missions,' why not broaden our horizons? I hope I haven't angered anyone who fills differently than I do. These are just the thoughts of an admitted beginner. -- View this message in context: http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171149.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
