Open jmorag opened 4 years ago
There's also hxt, which would allow us to use the schema, but apparently it's slow.
My main concerns are:
Adding as few transitive dependencies as possible. We already have xml
so using that would be ideal. But if this is unsuitable for you we could put the parsing functionality behind a Cabal flag, making it opt-in.
Pure interface. It should be possible to use the parser without IO
. Monad transformers such as conduit
or streaming-bytestring
are fine though.
Out of curiosity what did you plan to use it for? Parsing the entire MusicXML spec would be a very big undertaking, so I assume you want to focus on the subset relevant to your use case.
This will be my first time dealing with xml in Haskell, so I'm happy to start with xml
and a pure interface. If it becomes apparent that the library is too limited then I'll investigate the cabal flag route.
My use case is aggregating violin excerpts to create a database of fingerings. I'll mostly need to process small fragments of partwise scores generated with MuseScore and displayed in the browser with open sheet music display.
At minimum, I need to be able to process pitch, rhythm, and the string
and fingering
annotations inside technical
tags. Dynamics, articulations, and slurs would be nice so that pieces match up with what they look like in printed editions, but not absolutely necessary.
Sounds good. We currently don't have representations of strings number/fingerings but it should be easy to add this to Music.Score.Technique
. Let me know if you need any pointers.
I'd like to start working on
Data.Music.MusicXml.Read
. Do you have a preference between xml-conduit, xeno, hand-rolled megaparsec, or some other library?