andrewcoppin at btinternet.com
Sat Aug 25 16:02:29 EDT 2007
Evan Laforge wrote:
> To get this back to haskell, at the time I wondered if a more natural
> implementation might be possible in haskell, seeing as it was more
> naturally lazy. Not sure how to implement the behaviours though
> (which were simply macros around a let of *dynamic-something*). I'm
> sure people have done plenty of signal processing, and there's always
> haskore... but what about a sound generation language like csound or
> clm or nyquist? It could fit in nicely below haskore.
Indeed, you can write certain DSP algorithms beautifully in Haskell.
Now, if only it could talk to the audio hardware... (Or just use common
file formats even.)
> Also, as another reaktor user I agree it would have been so much nicer
> were it simply a real language. Drawing those boxes and lines and the
> complete lack of abstraction (beyond copy and paste) is a real pain.
> Supercollider is more promising in that way, but less polished of
> course. It also has that two-level imperative model though where you
> create and modify your signal graph with imperative techniques, then
> run it, rather than your program *being* the signal graph.
Reaktor has abstraction. You can build a gizmo that does something
useful, call it a macro, and then use it whereever you want.
If you want to build a gizmo that takes a siganl "x" and computes
"8*x*x*x - 8*x*x + 1" (i.e., the 4th Chebyshev polynomial), you've going
to have to draw *a lot* of wires! It would be nice if there was some
feature for quickly building complicated chunks of pure algebra like that.
It would also be nice if there were some way to *programmatically*
construct the graph... but never mind. (Maybe in Reaktor 6?)
More information about the Haskell-Cafe