Re: MusicXML exporter (was Re: Lilypond lobbying?)
Interesting discussion. And, being primarily a user and not (really) a developer, I hardly can wait to see where this will lead to. But I will be patient. The way I see it: The ideal case would be if a lilypond score that is converted to musicXML and then imported to some other music scoring software (Finale, Sibelius) the printed result would be identical. I don't think this ideal situation will ever exist. 1. My lilypond scores even don't give the exact same printed result when processed with different versions of Lilypond (for example 2.12.x vs 2.15.x). So what will happen when converted to MusicXML ? 2. Finale's and Sibelius' MusicXML import isn't 100% perfect either. Yes, when Finale exports a MusicXML file and then imports the same MusicXML file the result will be quite good. But I would not be surprised if importing MusicXML from other programs is much less perfect. Even if MusicXML was invented exactly to make that possible. But even with shortcomings, MusicXML would make it easier to convert/import Lilypond created scores to other programs. Post-editing may still be needed, but will much less work than when using MIDI export/import. -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Thu, 25 Aug 2011, Martin Tarenskeen wrote: But even with shortcomings, MusicXML would make it easier to convert/import Lilypond created scores to other programs. Post-editing may still be needed, but will much less work than when using MIDI export/import. I meant: will BE much less work than when using MIDI export/import :-) -- MT ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Aug 25, 2011, at 9:05 AM, Martin Tarenskeen wrote: 2. Finale's and Sibelius' MusicXML import isn't 100% perfect either. Yes, when Finale exports a MusicXML file and then imports the same MusicXML file the result will be quite good. But I would not be surprised if importing MusicXML from other programs is much less perfect. Even if MusicXML was invented exactly to make that possible. The issue with Finale and Sibelius exporting is user overrides. I can drag a markup over the last note in my score to be in the position of the title and it'll look just fine in Finale, but LilyPond will have no clue what to do with it. The nice thing about LilyPond is that, most often, things are what they are (titles are actually titles, etc.) Cheers, MS ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Michael Ellis writes: That sounds encouraging. So how far away are we from being able to handle a more realistic score, say a string quartet or a 4-part choral score with with lyrics and piano reduction? Quite far. Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Reinhold Kainhofer writes: I don't think it's that easy, in particular if you want to get output that you can send to a publisher without being thrown out of the office... I don't think this is a goal that anyone finds worthwile to work on or pay for. Consider the facts that --triggered by user requests iirc-- somewhere in 2002/2003 Han-Wen and I wrote a simple xml printing option, and it took me about an hour of research and an hour of work to get a simple working musicxml output going. If in eight years, no-one is interested in spending two hours for a hello world, or possibly 100 hours on a somewhat useful version, why do you think anyone would take on a job that may take a man year of work? Small steps: set easily attainable goals and add bonusses to that. If after a month of work there's still interest in improvement and the xslt option does not suffice anymore, go from there. Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Do., 25. Aug. 2011 09:11:49 CEST, Mike Solomon mike...@ufl.edu wrote: The issue with Finale and Sibelius exporting is user overrides. I can drag a markup over the last note in my score to be in the position of the title and it'll look just fine in Finale, but LilyPond will have no clue what to do with it. Yes, that's exactly one of the problems I faced with musicxml2ly Cheers, Reinhold ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Scribit Kieren MacMillan dies 24/08/2011 hora 20:00: 1) XML that captures only the music […] No: this is trivial to obtain from #2 or #3, via XSLT. To stay in mathematical lingo, I'd say the issue is that, although it is indeed trivial to obtain #1 from #2, the problem of getting #2 in the first place may be undecidable in the general case. I'm actually pretty certain that it is undecidable, as for any translation between two systems that are not equivalent, and that's why it will never be a perfect translation. So it will be an imperfect translation, covering as much as possible of the subset of Lilypond that is mappable onto MusicXML. And the real question is: how much do we cover at first? For what it's worth, I suspect that only exporting the music at first would be both relatively easy for the programmer (which may be me, so that's also appealing) and very useful to the users. One of the main needs seems to enable Lilypond composers to interact with publishers and engravers that use MusicXML-savvy software. In this case, the latter probably don't care about layout, they care about music (correct me if I'm wrong), because they want to specify a layout for themselves, according to their own guidelines and habits (which, yes, may well be worse than Lilypond's default automatic layout, but that's life). One other important need is the cooperation between composers. In this case, I suppose the not Lilypond-using composer probably doesn't want to tinker with the layout and send back the adjustements (BTW, would musicxml2ly really support that by outputting a meaningful, diffable to the original, .ly file? that seems insanely difficult). I expect most of them want to play the music and tinker with the music, to send back adjustments on the musical composition, not on its layout. And finally, I oh so strongly support the idea that you succeed with baby steps, even if the baby steps are directed towards a very ambitious goal. There should be a clear deliverable after a reasonably small amount of work. That is possible with #1, probably not really with #2 or a far less interesting product. Quickly, Pierre -- pie...@nothos.net OpenPGP 0xD9D50D8A signature.asc Description: Digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
As an engraver AND an independent publisher (both of printed, and soon digital interactive sheet music) it has been imperitive for my to find ways of efficiently separting the content from the actual publishing layout, so that changes to format and/or content can be easily managed without one being entirely dependent on the other. As a printing method, all my sheet music content is imported as linked graphics into my desktop publishing software so that as soon as a change is made and the relevant piece of music is recompiled, my layout document automatically is updated with the new graphic content. I don't know how a larger publisher would work, but I would imagine they would follow some similar principle so that tweaks could easily be made without having to modify the layout. I've been following the MusicXML export discussion closely, because I have also been looking at converting some sheet music content into MusicXML so it can be delivered by the Legato Music interactive sheet music viewer. As I delve deeper into the process, I don't see how I can avoid having to make formatting/layout changes to the version that is delivered as interactive sheet music. So that even if there were a smooth export process from Lilypond to MusicXML, I would still need to tweak the formatting and layout, perhaps significantly. It would almost make my life easier just to have a fast, precise way to deliver the content rather than a way of trying to retain the precise format. I wind up doing my formatting in Finale, since the Legato support folks recommend the MusicXML export from Finale (using Recordare's export plugins) as the cleanest output for the Legato music player. By the way, I'll contribute $75 US to the MusicXML exporter project(s). -- Jack Cooper, BerLen Music www.berlenmusic.com www.jack-cooper.com___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Il giorno mer, 24/08/2011 alle 06.23 +0200, Christ van Willegen ha scritto: On Wed, Aug 24, 2011 at 03:26, Jonathan Kulp jonlancek...@gmail.com wrote: On Tue, Aug 23, 2011 at 2:42 PM, Michael Ellis michael.f.el...@gmail.com wrote: Count me in for US$100 toward the project. Not sure how much programming I offered a $100 bounty a couple of years ago on this idea and it still stands. Count me in for €200. Me, too, would like to see Lilypond's usage expanded! ... and count me in for €50. I think that the new bounties should be added as a comment in issue 665: http://code.google.com/p/lilypond/issues/detail?id=665 I'll do it right now. Cheers, Federico ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Scribit Christ van Willegen dies 24/08/2011 hora 06:23: I offered a $100 bounty a couple of years ago on this idea and it still stands. Count me in for €200. Me, too, would like to see Lilypond's usage expanded! If memory serves, so far we have US$200, C$100 and €200. If I were to work alone on this bounty, that would allow me to allocate approximately 20hrs, which should clearly be enough to write a nice XML exporting in some schema mimicking Lilypond's representation, and probably also the XSLT transformation to MusicXML (I'm not sure how much time figuring it and then debugging it will take, it has been ages since I played with XSLT). Quickly, Pierre -- pie...@nothos.net OpenPGP 0xD9D50D8A signature.asc Description: Digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Pierre THIERRY writes:
[cc lilypond-devel]
If memory serves, so far we have US$200, C$100 and €200. If I were to
work alone on this bounty, that would allow me to allocate
approximately 20hrs, which should clearly be enough to write a nice
XML exporting in some schema mimicking Lilypond's representation, and
probably also the XSLT transformation to MusicXML (I'm not sure how
much time figuring it and then debugging it will take, it has been
ages since I played with XSLT).
To fix this bug, what we need is a very clear bug report to know when we
can close it. Actually, we require that for all bugs, so #665 should
never have been entered into the bug database like this.
What I would like to see attached to #665 is at least one .ly with
corresponding .xml with bonusses attached.
Possibly it's best to delay #665 and split it up into several different
issues (and attached bounties), each with it's own .ly -- and starting
with a most simple one.
It's only about an hour of work (see below) to convert a simple and
prepared .ly score to musicxml, see below.
Jan
From 8dd82d867fcf9b7b9a554016de02109ab6486a0c Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen jann...@gnu.org
Date: Wed, 24 Aug 2011 15:46:34 +0200
Subject: [PATCH 1/3] [MusicXML]: Hello world xslt stylesheet for MusicXML output.
---
xml/GNUmakefile |2 ++
xml/test-1.xml | 28
xml/to-xml.html | 17 +
xml/xml.ly | 16
xml/xml.xml | 38 ++
5 files changed, 101 insertions(+), 0 deletions(-)
create mode 100644 xml/GNUmakefile
create mode 100644 xml/test-1.xml
create mode 100644 xml/to-xml.html
create mode 100644 xml/xml.ly
create mode 100644 xml/xml.xml
diff --git a/xml/GNUmakefile b/xml/GNUmakefile
new file mode 100644
index 000..83d803c
--- /dev/null
+++ b/xml/GNUmakefile
@@ -0,0 +1,2 @@
+test:
+ xsltproc to-xml.html test-1.xml
\ No newline at end of file
diff --git a/xml/test-1.xml b/xml/test-1.xml
new file mode 100644
index 000..3c33cc8
--- /dev/null
+++ b/xml/test-1.xml
@@ -0,0 +1,28 @@
+music
+NoteEvent
+pitch
+ octave=1
+ notename=0
+ alteration=0
+/pitch
+duration
+ log=2
+ dots=0
+ numer=1
+ denom=1
+/duration
+/NoteEvent
+NoteEvent
+pitch
+ octave=2
+ notename=1
+ alteration=0
+/pitch
+duration
+ log=2
+ dots=0
+ numer=1
+ denom=1
+/duration
+/NoteEvent
+/music
\ No newline at end of file
diff --git a/xml/to-xml.html b/xml/to-xml.html
new file mode 100644
index 000..f1da85a
--- /dev/null
+++ b/xml/to-xml.html
@@ -0,0 +1,17 @@
+?xml version=1.0 encoding=ISO-8859-1?
+xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
+
+ xsl:template match=/
+xml
+ score-partwise
+ xsl:for-each select=music
+ xsl:for-each select=NoteEvent
+ pitchxsl:value-of select=pitch/
+ octavexsl:value-of select=pitch//octave
+ /pitch
+ /xsl:for-each
+ /xsl:for-each
+ /score-partwise
+/xml
+ /xsl:template
+/xsl:stylesheet
diff --git a/xml/xml.ly b/xml/xml.ly
new file mode 100644
index 000..2ade547
--- /dev/null
+++ b/xml/xml.ly
@@ -0,0 +1,16 @@
+\version 2.14.0
+
+testMusic = { c''4 \\ g'4 }
+
+#(use-modules (scm to-xml))
+
+#(ly:progress \nXML:\n\n~A\n (call-with-output-string (lambda (p) (music-to-xml testMusic p
+
+
+\header {
+ texidoc =
+ The input representation is generic, and may be translated to XML.
+}
+
+
+{ \testMusic }
diff --git a/xml/xml.xml b/xml/xml.xml
new file mode 100644
index 000..12ca68a
--- /dev/null
+++ b/xml/xml.xml
@@ -0,0 +1,38 @@
+music
+ type=score
+SequentialMusic
+SimultaneousMusic
+EventChord
+NoteEvent
+pitch
+ octave=1
+ notename=0
+ alteration=0
+/pitch
+duration
+ log=2
+ dots=0
+ numer=1
+ denom=1
+/duration
+/NoteEvent
+/EventChord
+VoiceSeparator
+/VoiceSeparator
+EventChord
+NoteEvent
+pitch
+ octave=0
+ notename=4
+ alteration=0
+/pitch
+duration
+ log=2
+ dots=0
+ numer=1
+ denom=1
+/duration
+/NoteEvent
+/EventChord
+/SimultaneousMusic
+/SequentialMusic/music
--
1.7.4.1
From ec8bf2adb089f4c1c38462afc1e8ec3fb0e33a60 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen jann...@gnu.org
Date: Wed, 24 Aug 2011 15:58:33 +0200
Subject: [PATCH 2/3] [MusicXML]: use apply-templates.
---
xml/to-xml.html | 35 ---
1 files changed, 28 insertions(+), 7 deletions(-)
diff --git a/xml/to-xml.html b/xml/to-xml.html
index f1da85a..3768641 100644
--- a/xml/to-xml.html
+++ b/xml/to-xml.html
@@ -4,14 +4,35 @@
xsl:template match=/
xml
score-partwise
- xsl:for-each select=music
- xsl:for-each select=NoteEvent
- pitchxsl:value-of select=pitch/
- octavexsl:value-of select=pitch//octave
- /pitch
- /xsl:for-each
- /xsl:for-each
+ xsl:apply-templates/
/score-partwise
/xml
/xsl:template
+
+
+ xsl:template match=EventChord
+xsl:apply-templates/
+ /xsl:template
+
+ xsl:template match=NoteEvent
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Wed, Aug 24, 2011 at 5:14 PM, Jan Nieuwenhuizen jann...@gnu.org wrote: Pierre THIERRY writes: [cc lilypond-devel] If memory serves, so far we have US$200, C$100 and €200. If I were to work alone on this bounty, that would allow me to allocate approximately 20hrs, which should clearly be enough to write a nice XML exporting in some schema mimicking Lilypond's representation, and probably also the XSLT transformation to MusicXML (I'm not sure how much time figuring it and then debugging it will take, it has been ages since I played with XSLT). To fix this bug, what we need is a very clear bug report to know when we can close it. Actually, we require that for all bugs, so #665 should never have been entered into the bug database like this. What I would like to see attached to #665 is at least one .ly with corresponding .xml with bonusses attached. Possibly it's best to delay #665 and split it up into several different issues (and attached bounties), each with it's own .ly -- and starting with a most simple one. It's only about an hour of work (see below) to convert a simple and prepared .ly score to musicxml, see below. Jan That sounds encouraging. So how far away are we from being able to handle a more realistic score, say a string quartet or a 4-part choral score with with lyrics and piano reduction? Cheers, Mike ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Am Wednesday, 24. August 2011, 23:33:02 schrieb Michael Ellis: On Wed, Aug 24, 2011 at 5:14 PM, Jan Nieuwenhuizen jann...@gnu.org wrote: It's only about an hour of work (see below) to convert a simple and prepared .ly score to musicxml, see below. That sounds encouraging. So how far away are we from being able to handle a more realistic score, say a string quartet or a 4-part choral score with with lyrics and piano reduction? I don't think it's that easy, in particular if you want to get output that you can send to a publisher without being thrown out of the office... Jan, you can take a look at the ~100 MusicXML files in input/regression/musicxml/ and at the corresponding output of musicxml2ly. The current approach is to modify the source file to add a \convertToMusicXML (or some similarly named function) to the music expression that you want to convert. However, I see several problems with this approach, which I might discuss separately. In short, the only way to make it extendable for the future (so that one day we can also export the layout) is to handle (MusicXML) export similar to MIDI generation, namely via translators that collect all events and all settings as they appear in the score. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Hi all, In short, the only way to make it extendable for the future (so that one day we can also export the layout) is to handle (MusicXML) export similar to MIDI generation, namely via translators that collect all events and all settings as they appear in the score. +1. KMac. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Wed, Aug 24, 2011 at 6:34 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi all, In short, the only way to make it extendable for the future (so that one day we can also export the layout) is to handle (MusicXML) export similar to MIDI generation, namely via translators that collect all events and all settings as they appear in the score. +1. KMac. This makes sense. A standalone converter would, essentially, have to duplicate Lily's internal logic. Why write the same code twice? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On 8/24/11 5:31 PM, Michael Ellis michael.f.el...@gmail.com wrote: On Wed, Aug 24, 2011 at 6:34 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi all, In short, the only way to make it extendable for the future (so that one day we can also export the layout) is to handle (MusicXML) export similar to MIDI generation, namely via translators that collect all events and all settings as they appear in the score. +1. KMac. This makes sense. A standalone converter would, essentially, have to duplicate Lily's internal logic. Why write the same code twice? Hence the importance of Jan's original comment. We need to clarify what is wanted. Do you want 1) XML that captures only the music (and could be imported into some other program which will make the layout decisions)? 2) XML that captures both the music and the layout (and could therefore be printed by some as-yet-unknown MusicXML printer)? 3) Some other XML that I haven't thought of? My sense is that item 1) is relatively inexpensive (as Jan has discussed), but that item 2) is relatively expensive (I think it's more than 100 expert hours, but that's just a wild stab). For me, item 1) is what we ought to be aiming at, at least initially. It seems strange to use Finale to print a layout defined by LilyPond. If you want to use a LilyPond layout and tweak a few things graphically, you should be using the svg output, IMO, and editing the svg. I think that holding out for 2) will probably delay completion of 1). But having a well-defined enhancement request will at least allow a developer to make a decision as to what they wish to attempt. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Am 25.08.2011 01:48, schrieb Carl Sorensen: On 8/24/11 5:31 PM, Michael Ellismichael.f.el...@gmail.com wrote: On Wed, Aug 24, 2011 at 6:34 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi all, In short, the only way to make it extendable for the future (so that one day we can also export the layout) is to handle (MusicXML) export similar to MIDI generation, namely via translators that collect all events and all settings as they appear in the score. +1. KMac. This makes sense. A standalone converter would, essentially, have to duplicate Lily's internal logic. Why write the same code twice? Hence the importance of Jan's original comment. We need to clarify what is wanted. Do you want 1) XML that captures only the music (and could be imported into some other program which will make the layout decisions)? 2) XML that captures both the music and the layout (and could therefore be printed by some as-yet-unknown MusicXML printer)? 3) Some other XML that I haven't thought of? My sense is that item 1) is relatively inexpensive (as Jan has discussed), but that item 2) is relatively expensive (I think it's more than 100 expert hours, but that's just a wild stab). For me, item 1) is what we ought to be aiming at, at least initially. It seems strange to use Finale to print a layout defined by LilyPond. If you want to use a LilyPond layout and tweak a few things graphically, you should be using the svg output, IMO, and editing the svg. I think that holding out for 2) will probably delay completion of 1). But having a well-defined enhancement request will at least allow a developer to make a decision as to what they wish to attempt. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user From what was discussed recently and in earlier discussions, I would really second your arguments. Providing option 1) would allow this bidirectional openness we are talking about. This will give * ... potential LilyPond users the trust that they can get their work back into the software they are used to (a similar effect that NTFS support under Linux had) * ... LilyPond users that for some reason or another are obliged to provide files for other software the possibility to do so. It may however be useful to discuss how a given approach to 1) would affect the implementation of 2) I think 1) should be done in a manner that can be further developped to a solution of 2) (As I know way too little about (Music)XML and practically nothing about LilyPond's internals, I can't actively participate in these necessary discussions.) Best Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Hi Carl, Do you want 1) XML that captures only the music (and could be imported into some other program which will make the layout decisions)? No: this is trivial to obtain from #2 or #3, via XSLT. 2) XML that captures both the music and the layout (and could therefore be printed by some as-yet-unknown MusicXML printer)? Yes: since Lilypond already generates this entire set of data, why not include it in the output? My sense is that item 1) is relatively inexpensive (as Jan has discussed), but that item 2) is relatively expensive (I think it's more than 100 expert hours, but that's just a wild stab). Maybe true… but that's what we should be going for, IMO. For me, item 1) is what we ought to be aiming at, at least initially. My question is this: In what format is the final, typeset music stream such that extracting the music information only would be massively easier than extracting the music and layout information? It seems strange to use Finale to print a layout defined by LilyPond. If you want to use a LilyPond layout and tweak a few things graphically, you should be using the svg output, IMO, and editing the svg. I think there are many things in the cracks that don't come through with just the music, but would be critical for translation to another program — for example, the cross-staff information that started this thread is clearly layout related, and not just music-specific. I think that holding out for 2) will probably delay completion of 1). Possibly… If we're talking about 10 hours for #1 (truly well done) and 500 hours for #2, then of course we should do that. If we're talking about 100 hours for #1, and 250 hours for #2 where the first 100 hours must be redone (assuming, for argument's sake, the two are radically different in execution), then I would say no. But having a well-defined enhancement request will at least allow a developer to make a decision as to what they wish to attempt. +1. Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Urs: I think 1) should be done in a manner that can be further developped to a solution of 2). Yes — exactly. Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On 8/24/11 6:00 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi Carl, My question is this: In what format is the final, typeset music stream such that extracting the music information only would be massively easier than extracting the music and layout information? I don't believe there *is* a final, typeset music stream. There is an input .ly code stream, which is converted to a stream-event stream. The stream-event stream generates a set of grobs. The grobs generate stencils. The stencils are printed on the page. IIUC, grobs have information about their cause, but stencils do not. And there is not a one-to-one correspondence between stencils and music events. For example, a chord made of three dotted quarter notes will generate three note-head stencils, one stem stencil, and one dots stencil. But as I read it, the XML would require three note objects, each having its own dot attribute. And the only layout information for the dot is whether the dot should be above or below the staff line. Perhaps it's possible to merge these two distinct views. But I think that Reinhold is exactly right, and that the only way to do it extensibly is with XML performers that will take stream events and convert them to XML. But how do we synchronize the performers and the engravers (which are setting things up to make the layout decisions)? That's the part I don't see right now. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
David, No: this is trivial to obtain from #2 or #3, via XSLT. You are using trivial like a mathematician, strictly interchangeable with doable. Actually, I was using trivial in two ways: 1. As a mathematician (yes, I've had several papers published in peer-reviewed journals), I was — as you noted — using it as a synonym for doable. 2. As a professional XSLT programmer (yes, some of my income comes from writing stylesheets), I was using it in the sense of extracting a strict subset of a XML tree is quite easy. Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Hi Pierre, What kind of funding would be possible I offer C$100 to the MusicXML project. If [Jan: hint hint!] my C$100 goes to creating a function (e.g., \displayLilystreamXML) which simply converts the raw Lilypond music stream (i.e., what we see with \displayMusic) as an XML blob, I'm happy to do for free all the XSLT coding required to turn that LilystreamXML into useable MusicXML. However, if the entire project will be in C++ and/or Scheme, I can offer little (to nothing) beyond the C$100. how many would we be on the project? If you scan the archives for XML, you'll find that a bunch of people have offered help on this. You'll probably want to do a fresh call for team members, though, as the thread has been dormant of late. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
Count me in for US$100 toward the project. Not sure how much programming time I can offer in addition, but I'll certainly be more than willing to test the XML output with Finale 2010 as I have a full copy. FWIW, If this is done well I think it will open LilyPond to more new users than you would ever guess. As a personal example, I sometimes collaborate with a composer/arranger who uses Finale exclusively. She composes on paper a real piano and then uses the Finale interface to her electric piano to enter the notes. She readily admits that entering dynamics, articulations, etc in Finale is time-consuming and clunky and that the LilyPond scores I produce are indeed better looking. If there were a reliable 2-way XML conversion between the two programs it would not only allow me to use LilyPond when we work together but would, I think, give her just enough enough incentive to invest the effort needed to start using LilyPond, too. Cheers, Mike On Tue, Aug 23, 2011 at 2:54 PM, Kieren MacMillan kieren_macmil...@sympatico.ca wrote: Hi Pierre, What kind of funding would be possible I offer C$100 to the MusicXML project. If [Jan: hint hint!] my C$100 goes to creating a function (e.g., \displayLilystreamXML) which simply converts the raw Lilypond music stream (i.e., what we see with \displayMusic) as an XML blob, I'm happy to do for free all the XSLT coding required to turn that LilystreamXML into useable MusicXML. However, if the entire project will be in C++ and/or Scheme, I can offer little (to nothing) beyond the C$100. how many would we be on the project? If you scan the archives for XML, you'll find that a bunch of people have offered help on this. You'll probably want to do a fresh call for team members, though, as the thread has been dormant of late. Cheers, Kieren. ___ 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
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Tue, Aug 23, 2011 at 2:42 PM, Michael Ellis michael.f.el...@gmail.com wrote: Count me in for US$100 toward the project. Not sure how much programming I offered a $100 bounty a couple of years ago on this idea and it still stands. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: MusicXML exporter (was Re: Lilypond lobbying?)
On Wed, Aug 24, 2011 at 03:26, Jonathan Kulp jonlancek...@gmail.com wrote: On Tue, Aug 23, 2011 at 2:42 PM, Michael Ellis michael.f.el...@gmail.com wrote: Count me in for US$100 toward the project. Not sure how much programming I offered a $100 bounty a couple of years ago on this idea and it still stands. Count me in for €200. Me, too, would like to see Lilypond's usage expanded! Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
