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.comReceived on Wed Jun 14 20:15:04 2006
This archive was generated by hypermail 2.1.8 : Wed Jun 14 2006 - 20:15:04 EEST