Re: MusicXML project platform

[Urs Liska]

Am Freitag, den 26.04.2013, 13:31 -0700 schrieb Curt:
> It seems to me that the problem (of exporting lilypond to music-xml)
> is semi-stalled in the stage of identifying dependencies.  
Yes. And in the situation that those who are the knowledge and insight
to move this on don't have the capacity to do so.

> I'm an enterprise java programmer and we often use dependency graphs
> to identify task relationships and next steps. 
> 
> I don't know C or Scheme but I'm tempted to try and at least
> understand the details of everything that needs to be done so it could
> be organized in terms of steps/tasks/stories/whatever, and maybe put
> some dependency graphs up on the wiki - would that be helpful?
I guess this would be very helpful.
In fact anything that could lead to a situation where people are able to
write actual code would be very helpful.
> 
> I guess I just have a couple of basic questions - 
> 
> It sounds like the music-stream is an internal structured
> representation of the music in the input file (generated after the
> input file is parsed).  It contains time-sorted information but not
> positioning information.
I think this is correct.
> 
> Regarding the strategy of converting the music-stream to musicXML
> first, and then finding other ways to add positioning information
> later - is that the only viable approach for enabling MusicXML export?
I'm not sure if I don't understand you or if you have misunderstood
something in the discussion.
The idea of parsing the input files doesn't have anything to do with
positioning information - there is even less positioning information in
the input file than in the music stream (if you'd consider timing
information as positioning information, just for the context).
Parsing the input file(s) should retrieve information such as titles,
maybe the general \paper variables. Maybe stuff like instrumentNames are
easier to retrieve there (don't know). And if it is important to know
about transposition this would have to be got from the input (I mean: if
the MusicXML file should know about the fact that some music is the
result of a transposition).

> Is converting the music-stream to music-xml as a "first step" a true
> prerequisite to adding positioning information to the musicXML export?
Probably not. Practically this is the result of the consideration that
this is a goal with a halfway realistic scope, so it could be tackled at
all. There is more or less unspoken agreement that a fundamental
solution would be preferrable but that there absolutely is nobody
capable of doing that.
Or to be more precise: There is no perspective on someone being so
interested in it to raise/give so much money that there would be enough
manpower to be set up.

Maybe it could actually help if someone volunteers to analyze the
situation and organize the stuff to a clear picture. Maybe this results
in the option to start work on rather small steps that one knows will
make sense in the big picture.

> 
> If the music-stream does not have sufficient information for musicXML,
> is it an option to improve the music-stream to contain more of that
> necessary positioning information?  Or what about improving the layout
> logic to maintain knowledge of the music-stream so the full xml export
> could be done at that later stage?
I can't judge this because I don't really know about the internal
processes.
As far as I have understood the relevant discussions at some stage in
the whole process the link between graphical objects and the structural
cause of the objects is lost. Of course it would be possible to change
that, but that would be a rather big operation.
> 
> If we merely export the pure "music-stream" as a first step, are we
> coding ourselves into a corner?  In other words, is that creating
> technical debt?  Is there an argument that another approach is really
> the "right way"?
I have no idea because I have no experience with largescale design
decisions.
> 
> Is it a hard prerequisite to add support for Guile 2.x to lilypond
> before we can enable MusicXML export?
As far as I have understood: no. If I'm right there are just some
Scheme/XML utilities available that depend on it. The fact that LilyPond
as a whole hasn't move to Guile 2.x is another topic.
> 
> Finally, is this the best venue to discuss this?  I was always
> assuming that people were already discussing this over on
> lilypond-devel.  Should we move all musicXML discussions over there or
> to a brand new list?
My intention with setting up this 'project' was to set up a dedicated
place for it. 
Maybe moving to lilypond-devel would be leave too many people out. I
have the impression that the people on lilypond-devel just can't afford
to give this project the attention it would need to overcome the
'semi-stall'.

Urs
> 
> My own sense after reviewing the discussions I've been able to find:
> 
> I suspect that focusing on music-stream export first is too
> "half-a-loaf" and would require major rework once we add positioning.
> And, that re-parsing the input file for positioning information is not
> as good an option as figuring out how to hook export logic into the
> lilypond positioning logic itself.  It seems the right way is to make
> the positioning logic maintain knowledge of music-stream.  And if
> sticking to the end-of-life version of guile makes this development
> unreasonable, we should first focus on lilypond supporting guile-2.x.
> 
> All that said, I recognize I lack perspective - thanks for any
> clarifications.
> 
> Thanks,
> Curt
> 
> 
> On Apr 26, 2013, at 7:46 AM, Urs Liska <address@hidden> wrote:
> 
> > Am 26.04.2013 16:39, schrieb Paul Morris:
> >> On Apr 26, 2013, at 8:59 AM, Urs Liska <address@hidden> wrote:
> >> 
> >>> in order not to let this discussion go asleep again, I set up a
> GitHub project
> >> Hi Urs,  Good idea.  I added the following which I dug up.  As well
> as the link to SXML support in Guile 2.0.
> >> -Paul
> > Thanks. That's what I intended with the Wiki.
> > 
> > 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