search

0xfe / vexflow

A JavaScript library for rendering music notation and guitar tablature.
http://www.vexflow.com
Other
3.91k stars 663 forks source link

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

Closed 0xfe closed 8 years ago

0xfe commented 8 years ago

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.

(Sorry, but I have to do this.)

Answers to some questions that have been asked so far.

ctzurcanu commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 https://github.com/0xfe/vexflow/issues/323#issuecomment-182708064.

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

mscuthbert commented 8 years ago

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 commented 8 years ago

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 https://github.com/0xfe/vexflow/issues/323#issuecomment-183484203.

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

coffeine-009 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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

freetomik commented 8 years ago

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

mturley commented 8 years ago

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.

mturley commented 8 years ago

Essentially I'm saying I would take this bounty if the resulting work was also covered under the MIT license as Vexflow itself is. Fostering the creation of a piece of such useful code without releasing it to the community for free and unrestricted use is something I don't necessarily agree with. But if an open-source vexflow-musicxml parser were to be created I want to have something to do with it.

mturley commented 8 years ago

Also the fact that there are already projects out there integrating MusicXML with Vexflow is an interesting conflict with your desire to have that capability be something you own.

mturley commented 8 years ago

Why don't we all, everyone in this thread who expressed interest in building this but having it stay open-source, build it together openly on github? Then when it's done, 0xfe can decide if he wants to grant us the bounty and have us split the $5,000, or cancel the bounty and just become another user of the new project.

0xfe commented 8 years ago

Folks. This bounty has now been closed. We'll try this again soon. :-)

SalahAdDin commented 8 years ago

How wins it?

rdp commented 8 years ago

I'd be interested in an open source version (anybody know how far off the ringw version is? Somebody said it can only render on a frame is that bad somehow?)

As a note for followers, I have created a list of options/alternatives to this (musicxml via html) here:

https://github.com/w3c/musicxml/wiki/MusicXML-HTML5

infojunkie commented 8 years ago

I've just tested the version at https://github.com/mechanicalscribe/vexflow-musicxml - I was happily surprised the demo still works for the latest version of VexFlow, with a deprecation warning that can be easily fixed. Functionality-wise, the import process still lacks a number of features, that you can check by comparing the VexFlow rendering of the imported demo MusicXML file versus MuseScore for example.

bneumann commented 8 years ago

I started using mechanicalscribe's version too but found the code a bit old fashioned. So I created my own Parser. Right now it is part of a bigger piece and also not complete in regards to all features because MusicXML is to be honest one of the worst XML formats i came along so far :) So it is not easy to get the conversion of voices and measure right.

But having vexflow accepting musicxml out of the box would be awesome. Count me in :)

SalahAdDin commented 8 years ago

Who win s this bounty?