(CLOSED) $5,000 Bounty: Create MusicXML Parser for VexFlow

[0xfe]

The Bounty (CLOSED)

A bounty of $5,000 (USD) will be awarded to the first person (or team) that can build a MusicXML parser that renders notation with VexFlow. The winner will also be eligible for up to $5,000 of additional development work (so really, this is a $10,000 bounty.)

The Goal

The goal is to implement a MusicXML parser that generates VexFlow notation, similar to how VexTab does.

• The parser must fully support the MusicXML 3 specification.
• Code must be written in ES6, well commented, and neatly organized.
• Code must work in all major browsers in both Canvas and SVG.
• Code is expected full test coverage, along with visual tests for each of the features (similar to the VexFlow tests.)
• VexFlow itself might need updates to support various MusicXML features -- you will send PRs to 0xfe/vexflow to implement these features.

How this will work

• If you're participating, contact me at mohit@muthanna.com and let me know. I encourage you to communicate with me regularly as you build this.
• Submit your finished repository to mohit@muthanna.com a tar.bz2 (or gz or zip or whatever) archive.
• Make sure to include a README.md file with build instructions, test instructions, documentation, etc.
• I will review and evaluate your work, and possibly send it back requesting minor changes, corrections, or more information.
• If I like it, you win! You get a check for $5,000, and we might work together on further improvements or other projects (also for which you will get paid.)

Terms and Conditions

(Sorry, but I have to do this.)

• You must be in a country where such bounties are legal, and where there are no trade restrictions placed by the US or Canada.
• Your participation in this bounty will not violate any law applicable to you, or disrupt or compromise any data that is not your own.
• You are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in this bounty, including payments.
• You must be at least 13 years old to participate. If you're under 18, you need to get guardian consent before any payment can be made.
• If you win, you must transfer full ownership of the code to me. This means that you may be unable to use, build derivative works from, or redistribute any code developed for this bounty.
• I reserve the right to modify, discontinue, or terminate this bounty at my discretion.
• I shall not be liable to you or to any third-party for any damages that you may incur as a result of your participation in this bounty.

FAQ

Answers to some questions that have been asked so far.

• Does it have to be pure ES6?
  Yes. ES6 all the way.
• Can I translate from another library or language (e.g., an existing C++ MusicXML parser.)?
  No. For ownership reasons, the code has to be entirely your own.
• Is there a deadline for this bounty?
  There is no deadline, but that may change in the future to something reasonable.
• Should I develop this in the open?
  Use good judgement. There's nothing stopping someone else from claiming your code as their own and submitting it.
• How much test coverage is good enough?
  It is important that the final product be easy to maintain, so full test coverage is a hard requirement. Yes, it's tedious, but you will build a better product that way.
• What runtime dependencies can I use?
  Please try to keep dependencies at a minimum. Ideally, the only dependency you will need is VexFlow, but I can grant one-off exceptions for lightweight open-source libraries such as lodash. If you're not sure, please check with me before you add a new dependency.
• I'm interested. How do I start?
  Just start. Feel free to send me an e-mail letting me know that you did (or not, it's entirely up to you.) Although, I encourage you to keep a line of communication open with me.

[ctzurcanu]

will the outcome be open source? I see: "If you win, you must transfer full ownership of the code to me. This means that you may be unable to use, build derivative works from, or redistribute any code developed for this bounty."
I hope that this does not mean you are closing the source.
I have looked into MusicXML 3 and implementing such a transpiler is certainly more effort than 5000 USD. It would be only worth only if the source remains open.

[mscuthbert]

People working on the project might want more information on "The parser must fully support the MusicXML 3 specification." -- there's not a single notation system out there (including Finale, Sibelius, MuseScore) that supports every feature of the MusicXML3 specification. What might be more realistic is to say that all aspects of the MusicXML 3 specification which have an equivalent in Vexflow need to be converted and all other aspects must be stored in some sort of object representation for future use once the relevant features are implemented. Otherwise the project will be a major expansion of Vexflow in non-MusicXML areas.

(I also might suggest awarding the bounty to a score-partwise only solution, since score-timewise has never been adopted, as well as omitting the OSF profile XSDs unless the plan is to use Vexflow for DRM sheet music sales).

Good luck to all!

[0xfe]

Hi Michael,

Thanks for the insight about MusicXML -- that was helpful. I want to say
something like "all parts of MusicXML used in typical classical and
contemporary music", but that might be too vague. I certainly don't want to
limit it to aspects that have equivalents in VexFlow, because I would like
VexFlow itself to be able to support everything required for typical
classical and contemporary music.

I would totally appreciate your input in clarifying the requirements here.
How's this for a start:

"The parser must support all aspects of the MusicXML 2.0 score-partwise DTD
that is uses in typical classical or contemporary music."

What do you think?

On Wed, Feb 10, 2016 at 11:53 PM, Michael Scott Cuthbert <
notifications@github.com> wrote:

People working on the project might want more information on "The parser
must fully support the MusicXML 3 specification." -- there's not a single
notation system out there (including Finale, Sibelius, MuseScore) that
supports every feature of the MusicXML3 specification. What might be more
realistic is to say that all aspects of the MusicXML 3 specification which
have an equivalent in Vexflow need to be converted and all other aspects
must be stored in some sort of object representation for future use once
the relevant features are implemented. Otherwise the project will be a
major expansion of Vexflow in non-MusicXML areas.

(I also might suggest awarding the bounty to a score-partwise only
solution, since score-timewise has never been adopted, as well as omitting
the OSF profile XSDs unless the plan is to use Vexflow for DRM sheet music
sales).

Good luck to all!

—
Reply to this email directly or view it on GitHub
#323 (comment).

Mohit Muthanna [mohit (at) muthanna (uhuh) com]

[mscuthbert]

Thanks Mohit.

The issue with asking for conversion of elements that don't have a vexflow equivalent is that this could be seen as obligating the user to implement this feature in Vexflow. For instance, does parsing the tag (which is often called a "feathered" beam: https://www.finalemusic.com/UserManuals/Finale2010Mac/Content/Finale/Beaming_feathered_beaming.htm) require the person writing the parser also to implement feathered/fanned beams in Vexflow? Or would it suffice to create a 32nd note beam and then store somewhere in the Vex.Flow.Beam object, {fan: accel}. I'd think that this should be enough; otherwise someone might wonder if, for instance, creating a system for figured bass for vexflow (which would be awesome! but hard) is part of the scope.

Here's an attempt at being more specific (it's not my money, but it's what I think would be ambitious but realistic).

All aspects of the MusicXML Partwise DTD (alternatively one can begin with the Partwise/Timewise XSD except those relating to Timewise only) necessary for typical uses in classical and popular music. Other aspects of MusicXML such as the Opus format, the OSF (Open Score Format) and the XSLT do not need to be supported.

These DTDs do not need to be supported except as they are necessary to support standard music notation: Opus, Container, Sounds, Standard MIDI. ISO Latin-1 and ISO Latin-2 entities can be supported via HTML escapes.

---

All elements in the XML document must be saved into a JSON or similar object that is stored in a logical place in the Vex.Flow object structure near to each element's place in the XML structure.

All elements that have a Vexflow equivalent as of the start of the contest must be converted to/from the nearest Vexflow equivalent.

[0xfe]

On Fri, Feb 12, 2016 at 3:50 PM, Michael Scott Cuthbert <
notifications@github.com> wrote:

Thanks Mohit.

The issue with asking for conversion of elements that don't have a vexflow
equivalent is that this could be seen as obligating the user to implement
this feature in Vexflow. For instance, does parsing the tag (which is often
called a "feathered" beam:
https://www.finalemusic.com/UserManuals/Finale2010Mac/Content/Finale/Beaming_feathered_beaming.htm)
require the person writing the parser also to implement feathered/fanned
beams in Vexflow?

Yes, adding features to VexFlow (within reason) is in-scope for this.

Or would it suffice to create a 32nd note beam and then store somewhere in
the Vex.Flow.Beam object, {fan: accel}. I'd think that this should be
enough; otherwise someone might wonder if, for instance, creating a system
for figured bass for vexflow (which would be awesome! but hard) is part of
the scope.

Yep, I agree. (BTW, Vexflow already supports figured bass :-) thanks Cyril!)

But, yes, I think what I'd like to see is all the common-case features
supported. The uncommon cases can be decided on a case-by-case basis.

Here's an attempt at being more specific (it's not my money, but it's what
I think would be ambitious but realistic).

All aspects of the MusicXML Partwise DTD (alternatively one can begin with
the Partwise/Timewise XSD except those relating to Timewise only) necessary
for typical uses in classical and popular music. Other aspects of MusicXML
such as the Opus format, the OSF (Open Score Format) and the XSLT do not
need to be supported.

These DTDs do not need to be supported except as they are necessary to
support standard music notation: Opus, Container, Sounds, Standard MIDI.
ISO Latin-1 and ISO Latin-2 entities can be supported via HTML escapes.

This sounds great. Thanks Michael.

---

All elements in the XML document must be saved into a JSON or similar
object that is stored in a logical place in the Vex.Flow object structure
near to each element's place in the XML structure.

All elements that have a Vexflow equivalent as of the start of the contest
must be converted to/from the nearest Vexflow equivalent.

I'm not sure about this, but I have to think about it. I'd like whoever's
working on it to have more design freedom, in particular because I think
are some design options that are more flexible than this (but have other
tradeoffs.)

(Not saying that these are bad requirements -- just probably too specific.)

—
Reply to this email directly or view it on GitHub
#323 (comment).

Mohit Muthanna [mohit (at) muthanna (uhuh) com]

[coffeine-009]

I am also interested in this parser. I need it for my startup project. Actually I've already started implementation and I am ready to implement it but only in case if I will have ability to use it on my projects or it will be open source project.

[rhalff]

Hi, I will have a go at this and in the process of doing so I came along this test suite:

http://lilypond.org/doc/v2.19/input/regression/musicxml/collated-files

I think it will proof to be very useful.

Also note that this project is already using MusicXML and vexflow: https://github.com/panarch/concerto

[freetomik]

Also note that this project is already using MusicXML and vexflow: https://github.com/panarch/concerto

This project also: https://github.com/ringw/vexflow/tree/musicxml

[sakulstra]

Hello there,
i'm also currently working on a parser... but actually I want to MIT license it so I can't participate here...

An answer to:

will the outcome be open source? I see: "If you win, you must transfer full ownership of the code to me. This means that you may be unable to use, build derivative works from, or redistribute any code developed for this bounty."

or

I am also interested in this parser. I need it for my startup project. Actually I've already started implementation and I am ready to implement it but only in case if I will have ability to use it on my projects or it will be open source project.

would be really interesting anyways.

Thanks in advance,
Lukas

[rhalff]

@freetomik although it's tempting to go directly from xml into rendering with vexflow, I think @mscuthbert is correct in first transforming the XML into a JSON format and treat vexflow as one of the renderers of this MusicJSON's format.

I think the schema of concerto https://github.com/panarch/concerto/blob/master/schema/musicjson.json is pretty much the description of what this MusicJSON format must look like.

MIT++

[panarch]

I tried using json schema but now I think it's better to use TypeScript rather than json schema.
What I felt was... running parser required many interval state variables but it wasn't easy to handle with only using json format.

So, I think making a schema based on TypeScript interface and implementing classes which extend that interfaces is a good choice to try.

[SalahAdDin]

@0xfe @freetomik yeah, what's about this https://github.com/ringw/vexflow?

[freetomik]

@SalahAdDin I'm afraid it can render only on canvas...

[mturley]

If you remove the following restriction:

If you win, you must transfer full ownership of the code to me. This means that you may be unable to use, build derivative works from, or redistribute any code developed for this bounty.

Then I will take this bounty. It is a lot more work than $5,000 if I were billed at my normal rate, but seeing as this is something we both need and a partnership could arise, it may be considered a fair bounty. But only if the closed-source and derivative-works restriction does not apply in any way.

I am building a web product that requires music notation engraving and MusicXML support. I was considering using vexflow, and I found this bounty by searching to see if such a parser already exists. I was planning to built it myself, and possibly keep it closed-source on my end.

But in exchange for your $5,000, I would happily open source my Vexflow-MusicXML repository so we both can use it, with licenses and special language ensuring that neither of us have exclusive right to the work, or any claim to derivative works on either side. I want to be assured that should I build something with my new package and it competes with something you build with it, we are allowed to compete fairly. When you look at this in that context, I might be taking $5,000 from my potential competitor in exchange for giving them access to a core part of the product we're competing to build!

Just a thought. I really want to build this, but if you don't budge on your condition to own my work, I will not take your money and I will keep my module closed-source for my own use.