[linux-audio-dev] Writing LADSPA plugins in high level language?
dominique.michel at citycable.ch
Thu Jun 15 06:02:34 EDT 2006
Le Wed, 14 Jun 2006 16:20:08 -0400,
Phil Frost <indigo at bitglue.com> a écrit :
> On Wed, Jun 14, 2006 at 10:48:54AM -0400, Paul Winkler wrote:
> > On Wed, Jun 14, 2006 at 09:59:48AM -0400, Steve wrote:
> > > 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.
> 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.
It is another problem here. Everybody know about peak oil, but we are managing all our ressources the same way, like a business that don't want t they consumers to pay. We are thinking at we have enough cash (or oil, or anything else) in the bank for ever. Fast processors (as solar panels) use indium, and for what I know, it will be no indium left in the wild in about 10 or 15 years. So the right question here is: who will have enough cash to buy those fast computers in 10 or 15 years?
More information about the linux-audio-dev