MusicXML follow-up

[Urs Liska]

Another follow-up multi-comment message:

Am Montag, den 22.04.2013, 10:49 +0200 schrieb Urs Liska:
> > [...] MusicXML [...]
> > 
> > indeed.
> > ;)
> I'd actually say it is crucial to have that in order to get LilyPond a
> foot in the publishing world. We can't expect publishing houses to
> easily switch their well-tested workflows. And it's hard to convince
> editors or organizations preparing editions to switch to a toolchain
> they can't use for delivery.
> 
I can only repeat this and promise to actively look for a way to put
some effort in.
In my presentation this seemed to attract attention, and people seemed
convinced that the text based approach with LilyPond could provide for
efficient workflows in scholarly projects. I'm especially pleased that
my advisor was impressed and convinced, as he is a) a very serious man
interested in the future of our profession and b) is quite into the
academic business. While this doesn't help us immediately I'm sure he
immediately grasped the importance of it (LilyPond, and its need for
being able to exchange with others), and it looked like he made notes
mentally to think about the issue ...


Am Dienstag, den 23.04.2013, 16:13 +0200 schrieb David Kastrup:
Urs Liska <address@hidden> writes:
> 
> > Am Dienstag, den 23.04.2013, 13:45 +0200 schrieb David Kastrup:
> >> Selling LilyPond with vaporware MusicXML makes only sense if we
want
> >> to
> >> hook people on LilyPond with the promise that they can take their
> >> scores
> >> into other products eventually.  
> > Yes, of course.
> >
> >> And that promise only makes sense if
> >> managing the scores with LilyPond is advantageous over managing the
> >> scores with whatever is supposed to read its MusicXML in the end.
> > That's what I'm absolutely convinced about by now.
> >
> > I can't imagine anything that beats a workflow with LilyPond, LaTeX
> > and Git to produce a book of sheet music.
> 
> Now that's a selling point.  The question is what MusicXML would be a
> selling point for.
> 
> a) you can export your existing scores to LilyPond
> b) you will be able to export your LilyPond scores to other
applications
> c) if convert-ly does not manage a conversion between LilyPond
versions,
>    maybe exporting and reimporting MusicXML will
> d) you can run a MusicXML business with LilyPond doing the hard work
in
>    the background
> 
> Which of those points might be important for whom?  And who of those
> would be able to provide enough funds to pay for external work (work
> that would not otherwise be happening)?
> 
Well, from my personal perspective we are talking about b)
The situation as I see it is now:
"we should advertise things we're good at." (Janek)
We can advertise things we're good at, in my case really superior
collaborative workflows. I can write a pitch that will convince many
musicologists that this is an issue that should at least be considered
thoroughly.
But then I have to say: "I'm sorry, but this applies only if you happen
to have a publisher who accepts printable pdfs. If the publisher insists
on finishing the score himself (and does so only with commercial
products) you're out of luck."
That's rather problematic as a selling position ...

Am Dienstag, den 23.04.2013, 16:13 +0200 schrieb David Kastrup:
> Maybe it's different for other applications, but for preparing
> > editions this is really awesome.
> 
> Not everybody is preparing critical editions.  So what parts of that
> awesomeness transfer to other uses?
> 
OK, let's try to figure this out.
Of course this awesomeness isn't based on MusicXML, this only plays a
role in it.
For me constituents of LilyPond's awesomeness are
- Git-driven (collaborative) workflows
- Potential for sophisticated modular file structures
- beautiful interaction with LaTeX text documents
- Even more potential for in-source documenting
- the fact that the out-of-the-box layout quality is so good that I
usually don't have to care about first making the score 'usable'. 

All this doesn't apply only to making scholarly editions but (to similar
degrees) to
- anybody creating scores of a certain complexity
- anybody doings serious work with scores
- anybody needing to create mixed text/music documents.

Even I have only recently come to appreciate all this, so there is some
potential to communicate these things more aggressively


Am Mittwoch, den 24.04.2013, 13:29 +1000 schrieb Vaughan McAlley:
> If MusicXML becomes an official or de facto standard, MusicXML export
> will be an essential feature of any music notation program that wants
> to be taken seriously. 
+1

> From my experience converting several of my old
> Finale scores to Lilypond, I would say that page formatting (as
> excellently as Lilypond does that) should be a low priority. A
> publishing house that accepts XML will inevitably need to clean it up
> and will most likely want to do the page formatting in their own
> program.
Exactly. I think there could even be _no_ effort in preserving page
formatting but only provide the bare structure.


Am Mittwoch, den 24.04.2013, 13:29 +1000 schrieb Vaughan McAlley: 
> I think that any music export/import without significant cleaning up
> is still a way away, so the priority as far as MusicXML export should
> be a good representation of “just the notes” (what is inside a bar).
> This would also be relatively easy to derive from Lilypond source.
But there are quite some things that we wouldn't want to interpret on
our own. For example questions like: Where does a variable end up to be
printed in the music stream?
I would suggest letting LilyPond do that work (as it does it already)
and capture the music stream as _one_ source of material.

> 
> > - We could probably also use code and ideas from Frescobaldi.
> 
> As far as I can tell, Frescobaldi seems to keep a very strong internal
> representation of Lilypond source for its own purposes, which could be
> worth utilizing.
> 
> 

Am Mittwoch, den 24.04.2013, 07:52 +0300 schrieb address@hidden:
> Python is a great tool for XML creation.  There is also
> http://okmij.org/ftp/Scheme/xml.html.  The advantage of doing it in
Scheme is that you are > building it directly into LilyPond. 

This is of course a good point.
OTOH the chance to get someone to help with a Python program should be
much greater than with Scheme. And I'd say anyone with good Scheme
skills willing to help could do more in actual LilyPond core
development.

> I'd take a stab in the dark and guesstimate that 60% of the LilyPond
user base that 
> needs MusicXML export would not be comfortable running a Python
script. 

Maybe this could be dealt with through an application disguising the
script once that is there?
And I'm not so sure about your 60% (although I'm biased of course): I
think that besides people who just want to share their work with friends
who can't compile LilyPond scores most of the target audience would be
people who prefer the LilyPond approach to develop scores but have to
deliver other file formats. And those with that profile should be able
and willing to run a script, just like convert-ly.