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