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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
