[Haskell-cafe] seems like I'm on the wrong track

[Michael Mossey]

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://www.nepls.org/Events/16/abstracts.html#hudak
> 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
> sounds[1].
> 
> 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.

Thanks,
Mike