Felix,
Thanks for clarifying. The evolution of mutopia moving to a git archive and
allowing submissions via an SCM has created a motivation for separating
music content form archive management content. It's a good idea: make
processing at the "pull acceptance" side of things easier. The person
accepting the pull is going to want to visually review the change. That's
time-consuming. If after review you can simply run a move-to-server script
without making further edits, that would be an advantage.
-glen
On Sun, Dec 16, 2012 at 1:58 PM, Felix Janda <felix.ja...@posteo.de> wrote:
> On 12/16/12 at 12:04pm, Glen Larsen wrote:
> > Felix, some comments below. -gl
>
> Thanks for your comments!
>
> > On Sun, Dec 16, 2012 at 3:29 AM, Felix Janda <felix.ja...@posteo.de>
> 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.
>
> lilypond has an -dbackend=null option which at least omits the pdf file.
> However when using this the -H option seems to be ignored...
> Maybe this will get more useful in a future lilypond version.
>
> I agree that in the usual case parsing is not difficult.
>
> > > 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.
>
> No, I meant something different. To summarise:
> The goal is to keep the least possible amount of information in the git
> repository. So all fields which are regenerated with each update should not
> be kept in the repository. Therefore the fields "lastupdated", "footer" and
> (standard mutopia) "tagline" should be removed. But the ID of the piece
> has to
> be kept, so add a new header field for that. When preparing the piece for
> publishing, add "lastupdated", "footer" (as mentioned above) and "tagline"
> according to the license and footer. The only thing which changes is the
> content
> of the files in the git repository.
>
> The preprint archive arxiv.org does something similar: They add a
> watermark to
> each preprint, but also offer the unmodified source files for download.
>
> Felix
>
_______________________________________________
Mutopia-discuss mailing list
Mutopia-discuss@mutopiaproject.org
http://lists.bcn.mythic-beasts.com/mailman/listinfo/mutopia-discuss
