Felix, some comments below. -gl
On Sun, Dec 16, 2012 at 3:29 AM, Felix Janda <[email protected]> wrote:
> Hi,
>
> just some thoughts on the current header parsing of Mutopia's software
> motivated by (not wanting to install java and) the thought that lilypond's
> language is so complex that parsing it should be left to lilypond itself.
>
> I noticed that lilypond has (since at least version 2.8.0) a --header
> option which could be used to retrieve header fields from the file,
> thereby letting lilypond do the parsing for us. Compared to the manual
> parsing this of course takes longer, especially since it seems that one
> has to compile the piece in order to get the header information, on the
> other hand one does not need to care where the header is placed in the
> file, whether there are multiple headers or variables are used inside
> the headers.
>
I will agree that the lilypond grammar is complex but argue that elements
like the header are regular enough that they can be parsed easily. If only
lilypond had, in addition to the --header switch, a switch that would exit
after the parse phase; as you mentioned, it simply takes too long to get a
single header value. Except in pathological cases, the parsing can be
scripted in python easily enough.
>
> In addition to retrieving header fields the Mutopia software also inserts a
> lastupdated field, a footer and a tagline to the header. So lilypond's
> --header
> option is not enough to stop the need of manually parsing the files. But
> one
> could put these fields into a separate header at the end of the files. In
> this
> way they take precendence over fields of the original header while keeping
> it
> intact.
>
I like the idea of a separate chunk of Mutopia header. The script would
have to continue scanning an entire file in the event an additional header
is at the bottom but it should do that anyway. Header keywords can also be
found within scores but typically that is just to specify the 'piece'
keyword.
>
> Maybe going a bit further one could strip the (new) files in the git
> repository
> from the (automatically generated) lastupdated, footer and tagline fields
> and
> add a new field like mutopiaId (I hope that the name is self-explanatory).
> When
> preparing the files for the server one adds the lastupdated field, the
> footer
> field with something like
>
> footer=\markup{\concat{"Mutopia-" \lastupdated "-" \mutopiaId}}
>
> and the tagline in a separate header to the end of each file. One
> advantage of
> this would be that if a update/correction of a piece sent via git is ok, it
> wouldn't have to be modified at all. For new pieces just the mutopiaId
> field
> needs to be set. Disadvantages would be the fact that there are now two
> versions
> of the files floating around and I'm not sure about legal matters: For a
> piece
> contributed in terms of a CC license then the only hint about this license
> in
> the files in the git repository would be the copyright field. Is that
> enough to
> comply with the license?
>
I read this as a desire to have the above markup as both the footer and
tagline. If you are suggesting that the copyright statement be removed from
the PDF, then I don't agree. Did I read that wrong?
The only thing about having a \mutopiaID tag is is that it reduces work in
a parsing tool. It just doesn't remove enough work to make it a worthwhile
change.
>
> I think that it wouldn't be too difficult to implement it, even in shell by
> tweaking and extending the current scripts. I haven't tried so, though. A
> bit
> of thought would need to be spent on the best way of how to handle
> multiple-ly
> pieces.
>
> Any more thoughts on this?
>
> Regards,
> Felix
>
> _______________________________________________
> Mutopia-discuss mailing list
> [email protected]
> http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
>
_______________________________________________
Mutopia-discuss mailing list
[email protected]
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
