Re: MusicXML project platform

[Curt]

It seems to me that the problem (of exporting lilypond to music-xml) is 
semi-stalled in the stage of identifying dependencies.  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 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.

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?

Is converting the music-stream to music-xml as a "first step" a true 
prerequisite to adding positioning information to the musicXML export?

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?

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"?

Is it a hard prerequisite to add support for Guile 2.x to lilypond before we 
can enable MusicXML export?

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 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