On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote: > There are, of course, languages like SuperCollider and CSound, which > ARE made for expressing audio algorithms. However, again they are > generally interpreted. You can run them, but they can't really be > considered equivalent to C, able to be compiled to code linked into a > program or plugin. (Though perhaps there exists ways of generating > plugins from CSound code, I wouldn't be surprised.)
There's also the compile-to-C approach, e.g. sfront which takes SAOL code (sort of like csound with cleaner / more modern syntax) and generates C. I hacked up an attempt at generating Jack apps with sfront, which I never finished or released. SAOL interest seems to be pretty dead anyway. > One thing I just learned about recently is Pyrex. It doesn't generate > stand-alone programs but is meant for creating libraries that can be > called from Python -- it generates C code from a Python-like language, > which is structured to be called from Python. This makes sense to > me... why worry about supported the millions of CPU architectures out > there when this is already taken care of by GCC. So instead of > generating ML, generate "portable ML" (i.e., C code), and let GCC take > care of the platform-specific work. I think this is a great idea, > except that I'd like to just write a whole program or plugin in it > instead of making something that is meant to co-exist with Python > "glue code". Pyrex is good for making faster python libraries, which is a great thing, but it won't help with the problem that you really don't want to be running a python interpreter inside a realtime dsp system. -- Paul Winkler http://www.slinkp.com