On Thursday, 24. June 2010 00:04:18 Alexander Solla wrote: > On Jun 23, 2010, at 1:50 PM, Martin Drautzburg wrote: > > I said that a rhythm is a series of Moments (or Beats), each > > expressed as > > fractions of a bar. But each Moment also has volume. So I could > > model rhythm > > as Pairs of (Moment, Volume). However I certanly do not want to > > specify both > > the Moments and the Volume, but rather compute one from the other. > > How about something like: > > type RhythmScheme = [(Maybe Moment, Maybe Volume)] > type Rhythm = [(Moment, Volume)] > > -- The resolution function will then be a function with type: > > rhythm_from_scheme :: RhythmScheme -> Rhythm > > -- Though you might want something like > -- rhythm_from_scheme :: RhythmScheme -> IO Rhythm > -- or > -- rhythm_from_scheme :: Seed -> RhythmScheme -> Rhythm > -- so that you can get and use random numbers, for example. > > > I guess the point of my suggestion is to let pattern matching in > function definitions deal with unification of constraints. Beta > reduction and unification are two sides of a coin.
Nice. But what if I have three or more values (and not just two). Then inside the rhythm_from_scheme function I will probably have functions like a->b->c, i.e. if two values are known I can compute the third. If only one value is known the result would be a partially applied function and I would need additional information to compute the result. So I will need more than just a Mabye, because I can either have Nothing, a value or a function. However I will need one such function for each permutation. The function a->b->c will not help me much if either b or c is known. This means I cannot stuff too many unknowns together, but I will have to layer the problem somehow, such that a 9tuple of unknowns is unified as three triples. I am still uncertain how to do this, but I believe it basically matches musical thinking. A composer cannot juggle 9 unknowns either without grouping them somehow. Another question is: how much past and future knowledge do I need. (I believe the fundamental property of music is that things are ordered). In order to compute Volumes from Moments I can get pretty much away without the past, but computing Moments from Volumes definitely requires knowing "where I am", because each new Moment has to be placed after a preceding Moment. Any ideas? -- Martin _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
