data at different stages
I'm working on an application for reading Music XML and manipulating it, including translating it into midi events. Storing music data can take place from different perspectives or requirements. - a literal translation of the MusicXML would store each note and marking on the page - another representation might relate to higher concepts: for instance, instead of storing individual dynamic markings and indications for swelling and ebbing of dynamics, it might create a single data structure which is a dynamic profile over time. Instead of storing all the markings over the notes individually (staccato, accents, slur marks, etc.) it might examine all the markings at once and compute concrete performance instructions note by note. There are about four distinct stages in processing the music, in which things become either more abstract (grouping together details into higher concepts) or more concrete (such as more literal performance instructions). One of the stages, by the way, tries to represent notes in a way such that they can be moved in time or "sliced out" without disturbing the continuity of the performance instructions. At first I created several different data structures, one for each useful stage. Many of the fields are copied literally. There are similar fields which need distinct names. This is starting to seem like a confusing mess. Another approach is to create one data structure which contains some "Maybe" type fields. When the processing reaches a certain stage, they are set to "Just <value>" if applicable to that stage. Otherwise they are set to Nothing. I didn't want to do this at first because it's too much like a sloppy script language. The type system of the compiler would no longer assist me in verifying the validity of the data at each stage. But it's turning into a mess- and the key reason it's a mess, I think, is that I DON'T have a clear model of the stages. It keeps changing as I expand the requirements of my program. What seemed like a useful representation last month needs to be changed today. Any ideas welcome. Dennis
You may be interested in the approach outlined in Wouter Swierstra's paper "Data Types a la Carte". There is also the 'syntactic' package which is based on Wouter's ideas. This is exactly the problem it was trying to solve -- having several slightly different versions of a data type, *without* having to do a lot of repetition (as in your separate data types approach) or throwing away the type system's help (as in your approach with Maybes). In any event it's a fun paper to read. -Brent On Fri, Jan 27, 2012 at 08:59:00PM -0800, Dennis Raddle wrote:
I'm working on an application for reading Music XML and manipulating it, including translating it into midi events.
Storing music data can take place from different perspectives or requirements.
- a literal translation of the MusicXML would store each note and marking on the page
- another representation might relate to higher concepts: for instance, instead of storing individual dynamic markings and indications for swelling and ebbing of dynamics, it might create a single data structure which is a dynamic profile over time. Instead of storing all the markings over the notes individually (staccato, accents, slur marks, etc.) it might examine all the markings at once and compute concrete performance instructions note by note.
There are about four distinct stages in processing the music, in which things become either more abstract (grouping together details into higher concepts) or more concrete (such as more literal performance instructions).
One of the stages, by the way, tries to represent notes in a way such that they can be moved in time or "sliced out" without disturbing the continuity of the performance instructions.
At first I created several different data structures, one for each useful stage. Many of the fields are copied literally. There are similar fields which need distinct names. This is starting to seem like a confusing mess.
Another approach is to create one data structure which contains some "Maybe" type fields. When the processing reaches a certain stage, they are set to "Just <value>" if applicable to that stage. Otherwise they are set to Nothing.
I didn't want to do this at first because it's too much like a sloppy script language. The type system of the compiler would no longer assist me in verifying the validity of the data at each stage.
But it's turning into a mess- and the key reason it's a mess, I think, is that I DON'T have a clear model of the stages. It keeps changing as I expand the requirements of my program. What seemed like a useful representation last month needs to be changed today.
Any ideas welcome.
Dennis
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
[Disclaimer - this response is a bit cheeky, but it may help save you some frustration down the line...] Hi David Do you have a concrete need for MusicXML? e.g. is it the only export format your preferred music program (Sibelius or whatever) supports? If you don't, but you are thinking about MusicXML because it looks like a "standard" you might want to reconsider. MusicXML really is a hideous format - representing notated music is though, western notated music enjoyed a thousand years of development before the invention of computers so it added many tricks that don't fit in well with syntax trees. MusicXML is a so-so attempt at a syntax representation. Personally I much prefer David Huron's Humdrum which represents just enough information for the task in hand, and it is a "meta-format" so what you can represent is flexible (extensible). If you want to use Humdrum in Haskell you would need to write you own parser - not a difficult task as the Humdrum format is simple and uniform. Best wishes Stephen
Hi Dennis
Apologies - sorry about the typos in the last message
I meant "Hi Dennis" - a mix up as I was thinking of David Huron the
Humdrum author.
Also the text should say representing notated music is _tough_
("though" for "tough" gets through the spell check).
Stephen
On 28 January 2012 08:00, Stephen Tetley
[Disclaimer - this response is a bit cheeky, but it may help save you some frustration down the line...]
Hi David
Do you have a concrete need for MusicXML? e.g. is it the only export format your preferred music program (Sibelius or whatever) supports?
If you don't, but you are thinking about MusicXML because it looks like a "standard" you might want to reconsider. MusicXML really is a hideous format - representing notated music is though, western notated music enjoyed a thousand years of development before the invention of computers so it added many tricks that don't fit in well with syntax trees. MusicXML is a so-so attempt at a syntax representation.
Personally I much prefer David Huron's Humdrum which represents just enough information for the task in hand, and it is a "meta-format" so what you can represent is flexible (extensible). If you want to use Humdrum in Haskell you would need to write you own parser - not a difficult task as the Humdrum format is simple and uniform.
Best wishes
Stephen
participants (3)
-
Brent Yorgey -
Dennis Raddle -
Stephen Tetley