[Haskell-cafe] seems like I'm on the wrong track
mpm at alumni.caltech.edu
Wed Dec 2 10:32:20 EST 2009
Stephen Tetley wrote:
> Hi Mike
> There used to be some slides available commenting on Haskore's CSound
> interface. But they seem to have vanished (I have a copy rendered to
> pdf when they were available). Like all slide presentations there's a
> lot of reading between the lines to get a good picture after the fact:
> http://plucky.cs.yale.edu/cs431/HasSoundNEPLS-10-05.ppt -- vanished
This looks like a great resource. Maybe Dr. Hudak can get me a copy. He
clearly has the experience to implement a CSound "compiler" as gracefully
as anyone could.
> Maybe you're doomed to frustration though trying to implement your
> system in "Haskell". For the argument I'm about to make, I'd say a
> working programming language has two things - syntax, semantics and
> libraries and a repertory of prior art. Stateful programming clearly
> has some syntax burden in Haskell, stateful monadic programming has
> some benefit of 'stratification' - you have precise control of 'what
> state is where'. It's a matter of taste whether you like Python's
> flexibility or Haskell's, erm, 'locality' (precision?).
> As for the second half of what you get from a programming language,
> your system description frames what you want to do with an emphasis on
> dynamic aspects. This seems a good way off from the prior art in
> Haskell. For instance there are Haskell synthesizers - George
> Giorgidze's yampa-synth and Jerzy Karczmarczuk's Clarion (actually in
> Clean, but near enough). Here you build signal processing modules -
> unit generators, of course - Yampasynth uses arrows to do this Clarion
> uses infinite streams. With both you would build a synthesizer
> statically from unit generators and somehow run it to produce
> There is also the prior art of embedded hardware description
> languages, Lava, Hydra, Wired, Gordon Pace's HeDLa, soon Kansas Lava.
> One could view constructing synthesizers from unit generators as
> usefully analogous to constructing circuits - and certainly if you are
> 'compiling' to another system to do do the real work (in your case
> CSound) the papers on Wired, HeDLa, and Kansas Lava have useful
> insights on 'offshoring' compilation. But again these systems have
> strong bearing in the 'static description' of a circuit rather than
> its dynamical operation.
Thanks for this detailed review. I will investigate these things.
My system sits halfway between a low-level signal processor language like
CSound and a high-level music description language like Hudak's Haskore. My
work as a composer will be done at the highest level possible, which means
thinking in terms of "notes"---things that go "boo" at a certain time,
place, frequency, amplitude, timbre, etc. But I want to express things
beyond, say, MIDI, like indicating that a group of notes should be played
legato---which doesn't mean "play them individually with no separation of
notes" but actually means "modify the csound instrument's behavior at the
time of note connections." So in one small breath I can say, "Make this
legato" and at the low level the elves are scurrying around like mad,
rearranging code, changing out instruments, merging notes, etc.
I also have a bad case of "Not Invented Here Syndrome"---seriously, I want
to use this system to do experimental composition, by which I mean any
crazy idea I dream up can be implemented by adding to or modifying my
system, which gives me a preference to write it myself.
> If neither of those 'genres' is close to what you really want to do
> then the Haskell prior art is running a bit thin. You could look at
> dataflow - the dynamic PD / Max systems are often describe as a
> dataflow systems. There are some outposts in Haskell of dataflow
> programming - Gordon Pace has an embedding of Lustre available from
> his homepage and there has been work on dataflow programming via
> comonads. There is also reactive programming, but musical examples are
> thin on the ground
> (nonexistent?) so it might be a long haul to come up with something.
But this all sounds great to study.
More information about the Haskell-Cafe