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
*****************************************
