14 Jun
2006
14 Jun
'06
12:49 p.m.
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