Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

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" 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 <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.
> > > > Urs
> > > >
> > > > > Craig
> > > > >
> > > > >
> > > > > 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 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 <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 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
> > > > > > > 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