Re: Google Summer of Code 2015

[Urs Liska]

Am 05.03.2015 um 18:38 schrieb Paul Morris:
> Urs Liska wrote
> > One thing to keep in mind with this is not to be too focused on MusicXML.
> > MusicXML is _one_ XML format, and not the best.
> > I think the first step should be a generic XML representation, so
> > LilyPond could read XML files - and also write to them. MusicXML or MEI
> > or whatever other XML format one might come up with should then be
> > transformed to that generic LilyXML.
> Just to clarify for David G, as I understand it the Frescobaldi team are
> working on creating an XML representation of LilyPond's internal Scheme
> music data that LilyPond creates from the user's .ly input file (like you
> can see with \displayMusic).[0]  As I understand it, part of the motivation
> for that is to be able to use Python's XML tools to do things with that
> "LilyXML" (like converting it to and from MusicXML and MEI).  (Frescobaldi
> is a Python app.)  So that's what Urs is describing here.
>
> David K. is suggesting another approach, which I assume would entail using
> Guile/Scheme's XML tools[1] to automatically create a Scheme representation
> of an XML document (either MusicXML or MEI) and then use Scheme to do the
> conversion into LilyPond's internal Scheme music data "format" (bypassing
> LilyPond's input plain text format).
>
> Basically one approach is "get the data into XML format and then use Python
> on it" while the other is "get the data into Scheme format and use Scheme on
> it."

That's not _completely_ true.
What you describe about the "Frescobaldi" approach is true, at least 
that's where this approach is coming from. However, we are discussing 
the other one too, because it would of course be very helpful to have as 
much as possible done _within_ LilyPond. So this is not necessarily an 
antagonism. By contrast, if someone were working (e.g. through GSoC) on 
a way to represent LilyPond as XML the Guile way that would be very 
interesting also for "third-party" development.

> David G., can you tell us about your experience/qualifications, especially
> in terms of C++, Scheme, and Python, and how this might affect what project
> you'd like to take on?

+1

> (I agree with Urs that MEI would be great to have, but I think MusicXML
> would take priority.

I didn't want to say MEI had priority over MusicXML. What I mean is that 
we should try to be as generic as possible in order to enable the most 
diverse applications.

> Also, I think I read that someone will be working on a
> MEI-to-LilyPond script for a particular project.[2])

Oops, I didn't read this close enough, stumbling over the historical 
area I'm not that interested in. Will have to catch up ...

Urs

> -Paul
>
> [0]
> http://lilypond.1069038.n5.nabble.com/converting-LilyPond-score-to-XML-tc171447.html
> [1] https://www.gnu.org/software/guile/manual/html_node/SXML.html#SXML
> [2]
> http://lilypond.1069038.n5.nabble.com/Draft-Extended-mensural-notation-support-tc172204.html
>
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/Google-Summer-of-Code-2015-tp172600p172659.html
> Sent from the Dev mailing list archive at Nabble.com.
>
> _______________________________________________
> lilypond-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-devel