[<<][meta][>>][..]
Tue May 14 11:41:42 EDT 2013

KVR / music-dsp / pd-list post

Is there anyone here interested in Functional Programming and C code generation for DSP code?

I'm working on a system for DSP code development based on the principle of Abstract Interpretation
http://en.wikipedia.org/wiki/Abstract_interpretation

Basically, it will allow several interpretations of a single specification program:
- specification as a pure functional program
- imperative C code generation (for passing to C compiler or LLVM)
- Z transform for frequency plots of (linearized) transfer function
- automatic differentiation for all kinds of derivative-based tricks
- ...

It is written in Racket
http://racket-lang.org/

It's starting to get to a point where it is actually useful (there is a basic synth core) and could use some feedback, but please note it is very experimental and still needs a lot of work. Familiarity with Racket is probably a prerequisite at this point to make sense of it. Current code is here:
http://zwizwa.be/darcs/meta/rai/

It is part of a darcs archive that can be fetched using
darcs get http://zwizwa.be/darcs/meta

[1] http://www.kvraudio.com/forum/viewtopic.php?p=5355958#5355958
[2] http://www.kvraudio.com/forum/viewtopic.php?p=5355958#5355958




This is a very valid point, and I must say my main point of dispair.  Maybe it is so that a language like C (or C++ for those so inclined) is really the best available abstraction once you take all these tricks into account.  Ultimately we write code for state machines, not some pretty highlevel model interpreter.  Ultimately, we need to just make it work.

What interests me though is how many of those hacks and tricks are essential?  When you start out with a simple language that makes the dirty hacks impossible but somehow incorporates the "smart" ones as simple abstractions, are you left with something that is uglier than what you would do in straight C with a good coding standard?

Another approach I've been thinking of is to go the other way: write analyzers for C programs.  However in this case, the unessential hacks get in the way very quickly simply because C is too permissive and doesn't capture enough structure.  There has to be a middle way somewhere, but it could very well be that this only works for a limited set of primitive combinations.







Another valid point.  Maybe to clarify that I am not talking about stateless functions at the sample level.  I'm talking about functional / stateless the same way I understand is done in Faust: at the stream level.  I'm looking at functions as stream operators, where delays and IIR filters are implemented in one interpretation as a C struct containing current state.  Essentially, update functions in

 (In another interpretation, the stream operator can be a linearized transfer function).  However, the program never manipulates this state directly.  It is essentially what is abstracted in the ArrowLoop class in Haskell.




[Reply][About]
[<<][meta][>>][..]