[Haskell-cafe] music-related problem
erik.flister at gmail.com
Sun Jul 4 22:07:55 EDT 2010
> I don't understand how this turned into an argument about simplicity. I
> never said it was complex.
i wasn't arguing, just confused about what you were asking cuz i didn't see
what wasn't straightforward. so i addressed the straightforward
interpretation in order to ask what that was missing. :) looks like
polyphony is the issue, so i think you need a directed acyclic graph (DAG).
since every note has at most one pre-Tie and one post-Tie, i guess you don't
need a general DAG -- but a graph library would have the algorithms for
walking the Ties (ie, dfs, components, reachable, etc. in the mentioned
I conceive of this problem as multiple passes. On the first pass, I
> translate XML notes into a convenient internal representation, on the second
> pass sort them, then make a pass to figure out ties. Whether this is the
> best approach, I do not know.
sure that makes sense, i was just addressing the last pass, the matter of
wiring up the tie references.
> Regarding my use of Rational, it's because I'm representing *notated*
> durations or positions in time, which are always fractions of integers.
> Suppose I give the command to my program to play via midi everything from
> bar 1 beat 1 to bar 2 beat 2 1/2. I want to use Rational so I know 2 1/2
> means 2 1/2 and not 2.49999999999.
i wasn't suggesting anything Numeric for durations -- those are NoteDurs
like (Dotted $ Triplet Half). you don't need numerics until resolving
temporal locations, like milliseconds or subdivisions of a beat. those may
be irrational numbers (consider if the tempo is irrational, or tiny random
jitter in timing) -- though it's a totally pedantic point on my part and
realistically won't matter. ;)
> I don't quite get this:
> > forall x. (Real x, Fractional x) => x if you're picky.
just being agnostic about the true representation as long as you have
(/), compare, realToFrac,
toRational. the client can choose some concrete representation like
Rationals, Floats, Doubles, some Fixed resolution, some C type, something
they make up, etc. space or speed or compatibility may trump precision for
(*) I may want to use the location of a note (bar and beat) as the key in a
> Map, which I believe should be done with Rational and not Float.
location needs subdiv, which is (very pedantically) not Rational. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe