Send Beginners mailing list submissions to beginners@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/beginners or, via email, send a message with subject or body 'help' to beginners-requ...@haskell.org
You can reach the person managing the list at beginners-ow...@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Beginners digest..." Today's Topics: 1. data at different stages (Dennis Raddle) 2. Re: data at different stages (Brent Yorgey) 3. Re: data at different stages (Stephen Tetley) 4. Re: data at different stages (Stephen Tetley) ---------------------------------------------------------------------- Message: 1 Date: Fri, 27 Jan 2012 20:59:00 -0800 From: Dennis Raddle <dennis.rad...@gmail.com> Subject: [Haskell-beginners] data at different stages To: Haskell Beginners <beginners@haskell.org> Message-ID: <CAKxLvoq2pTUOS9nwx5D6inck3nT8Tgd=EGBKk4VyH=fxmmm...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.haskell.org/pipermail/beginners/attachments/20120127/7e678303/attachment-0001.htm> ------------------------------ Message: 2 Date: Sat, 28 Jan 2012 00:39:42 -0500 From: Brent Yorgey <byor...@seas.upenn.edu> Subject: Re: [Haskell-beginners] data at different stages To: beginners@haskell.org Message-ID: <20120128053942.ga9...@seas.upenn.edu> Content-Type: text/plain; charset=us-ascii 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 ------------------------------ Message: 3 Date: Sat, 28 Jan 2012 08:00:04 +0000 From: Stephen Tetley <stephen.tet...@gmail.com> Subject: Re: [Haskell-beginners] data at different stages To: Dennis Raddle <dennis.rad...@gmail.com> Cc: Haskell Beginners <beginners@haskell.org> Message-ID: <CAB2TPRBksQurQmnpDeiho4JLAOM_-s=3o2d-0xshrvphzx4...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 [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 ------------------------------ Message: 4 Date: Sat, 28 Jan 2012 08:08:42 +0000 From: Stephen Tetley <stephen.tet...@gmail.com> Subject: Re: [Haskell-beginners] data at different stages To: Dennis Raddle <dennis.rad...@gmail.com> Cc: Haskell Beginners <beginners@haskell.org> Message-ID: <cab2tprczvrnkwrqx6yjd3wjd5gprwnebpxpjnzgqm-pupgb...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 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 <stephen.tet...@gmail.com> wrote: > [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 ------------------------------ _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners End of Beginners Digest, Vol 43, Issue 32 *****************************************