|
From: | Urs Liska |
Subject: | Re: ScholarLY - introduction and call for collaboration |
Date: | Mon, 02 Feb 2015 19:37:26 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
Am 31.01.2015 um 18:23 schrieb Urs Liska:
Am 31. Januar 2015 18:14:23 MEZ, schrieb Craig Dabelstein <address@hidden>: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 < address@hidden> wrote:Hi Urs, I followed your advice re: file structure -- "main-init.ily" hasannotate,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 <address@hidden>wrote:Am 31. Januar 2015 03:05:24 MEZ, schrieb Craig Dabelstein < address@hidden>: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.UrsCraig On Sat Jan 31 2015 at 8:05:57 AM Urs Liska <address@hidden>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 immediatelynoticedandwanted to tell you about, even before I realized you had aproblemwith theannotations. I thought this would be only a matter of cleancodingbutsomehow this triggered your issue. Each annotation is generated multiple times - once for each timeyouincluded annotate.ily. So you should only include it once, which is what I would haverecommendedanyway. Usually I have a set-up along these lines: One main-init.ily file with global definitions and includes thatapply forany 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 orpartcompilation The score file includes score-init.ily and each part fileincludespart-init.ily This way everything is only included once, and can also bemodifiedin onesingle place. ### However, this is only a case of sloppy coding and shouldn't havesuchconsequences, so I'll have to sort it out on "my" side. It seems each time you include annotate.ily you create a newinstanceofthe engraver. I had thought that re-including a file would simply bere-definingeverything and be a waste of resources. But obviously when you do\consistsomething multiply in a context it is actually doubled. So I assume the function definitions (and the engraver) areredefinedsolater includes simply overwrite the earlier ones. But as theengraverisconsisted in the Staff context multiple times it is also executedmultipletimes. If you carefully inspect the console output you will notice thattheoutput file is rewritten multiple times too. Interestingly the engraver uses a global annotations list, so inafirstrun annotations are appended to this list and in a second runtheyarefinally written out. (This is done to have a list that can besortedbeforeoutputting). This seems to result in all instances of the engraver addingtheircopy ofan annotation to the list so not only the output file isgenerated Ntimesbut 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 thatgracefully. Iwillthink about if I just suppress multiple includes or if I find abetter wayto structure the code in the first place. Thanks for reporting Best Urs On Fri Jan 30 2015 at 11:26:57 PM Urs Liska <address@hidden>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 theLilyPondfile?Urs These are based on the sample file included : Ah, OK. I see the offending LaTeX code, but I'll have to look into thereason whythis is generated. The #f in the first line of the .inp file is the result ofexportingsomething that evaluates to false. Urs It turns out that custom annotation types were not properlyhandled.\annotate looks up the LaTeX value in an alist dictionary, andforcustomannotations this simply returned "#f". Pushed a fix, should work now. Thanks for the report. Best Urs _______________________________________________ lilypond-user mailing list address@hidden https://lists.gnu.org/mailman/listinfo/lilypond-user_______________________________________________ lilypond-user mailing list address@hidden https://lists.gnu.org/mailman/listinfo/lilypond-user
-- Urs Liska www.openlilylib.org
[Prev in Thread] | Current Thread | [Next in Thread] |