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 <u...@openlilylib.org> wrote: > Am 26.04.2013 16:39, schrieb Paul Morris: >> On Apr 26, 2013, at 8:59 AM, Urs Liska <u...@openlilylib.org> 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 > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
