On Wed, Jun 14, 2006 at 02:09:33AM -0400, Lee Revell wrote: by properly designing the interpreter? <sk>

Steve Harris wrote: That's not necessarily true. If you can live without collecting cyclic structures then a simple reference counting scheme will do, which is very cheap and simple to implement. And SuperCollider shows that the more general case is tractable, too, at least in languages designed specifically for that purpose. But I agree, there is no point in using interpreted languages to program DSP algorithms which operate on the sample level. If properly designed, they are o.k. for providing the glue between ready-made units which operate on the block level (like SC does, and CSound, and ...), but not for sample-level stuff. That's what compiled languages like Faust are for. Even when computers get a lot faster than they are now, we don't have any cpu cycles to waste on number crunching. I think that the scientific computing community will object to that. "Real programmers use Fortran." ;-) Yes, because it will do optimizations on the expression level that your C compiler can't do, and that you might not bother to do manually. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

Frank Barknecht wrote: Sure, but unfortunately all those nice little ugens don't grow on the trees, they must be programmed, too, and then you _are_ working on the sample level. ;-) This is where most of the heavy-duty number crunching takes place, and there you want a compiled language. That's what languages like Faust are for, to provide an alternative to C and assembler for the low-level stuff. (Not sure about snd, does it compile to native code which can execute in realtime?) Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag

I think this is a worthwhile topic actually... There is currently a shortage of interest in developing good alternative NATIVE machine-language-compiled languages. Although I have been programming C/C++ for a long time, I have lately been getting into Python and I really like it... Really, there's no REAL reason we can't use other languages for writing audio stuff, except that most newer languages tend to be designed for either interpreters or bytecode machines. The reason is straight-forward: Interpreters and virtual machines are way easier to debug and can take care of a lot of the nitty gritty work (like garbage collection), which is perfectly fine for things like application-writing, which tend to be I/O-bound processes. However, for certain tasks, like audio, it's still necessary to get the optimization and lean code that can only be generated by a good C compiler. While C is a great language, other languages frankly do provide nicer ways of expressing logic. Especially for things like audio, languages that offer vector operations might be much better suited. (For example, in the academic world, lots of audio research is done in Matlab for crying out loud... which I don't think is necessary the best language, but is well-known and good for what they are using it for. Now imagine being able to directly compile that into a VST or LADSPA or DSSI instead of having to manually translate it to C..!) Additionally with the availability of hardware that is optimized for vector processing (GPUs, the Cell processor, etc..), languages that can properly (and automatically) take advantage of it would be welcome. So why is the rest of the programming world able to move on to new languages while audio and realtime people are still stuck in the 80's with C? It doesn't seem fair, and the only reason is that the world has lost interest in native compilation so there is currently little effort being put into developing new languages that can be used for realtime processes. 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.) 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". I'm definitely going to check out Faust too, as I hadn't heard of it before. Steve On 6/14/06, Phil Frost &lt;indigo(a)bitglue.com&gt; wrote:

On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote: 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. 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

On Wed, Jun 14, 2006 at 10:48:54AM -0400, Paul Winkler wrote: That's not entirely true. I once wrote an OS where the filesystem and ATA drivers were written in Python, which was accomplished by linking the kernel with libpython (no joke). Lower levels, like the memory manager, were written in Pyrex. In the end it was pretty slow and useless, but it did run, and at one point I managed to get on IRC with it :) Pyrex is pretty much Python + C, only the C syntax is changed to look more like Python. If you use only C types, then the code output by Pyrex will not depend on Python (except some of the module metadata it generates, but the generated functions can be executed without it). The problem though is that it's just C with a different syntax. Re. lack of interest in developing new compiled languages, see Wirth's law: <http://en.wikipedia.org/wiki/Wirth%27s_law>. The good news is that in a few years, computers will be so damn fast that using Python to write audio plugins won't be so bad. Of course when that happens, we will have some fancy new language which is even slower, and manages to consume enough resources that it will seem as if computers are not in fact getting faster. You might as well just expect using a 20-year old language for all your audio work forever.

On Thu, Jun 15, 2006 at 12:02:34PM +0200, Dominique Michel wrote: I didn't say it wouldn't *work*. You're the one who said "pretty slow and worthless" :) -PW -- Paul Winkler http://www.slinkp.com