Re: [linux-audio-dev] Python

From: David Cournapeau <cournape@email-addr-hidden>
Date: Wed Feb 07 2007 - 16:57:10 EET

On 2/6/07, Stephen Sinclair <radarsat1@email-addr-hidden> wrote:
> > chuck already has its own pure-openGL GUI toolkit, used for things like Audicle, and Tapestrea. i doubt youd get anything similar performance wise with python+canvas-of-choice.
> >
> > not sure how you program the chuck canvas though. i dont think its actualy in chuck the language?
>
> Tapestrea and Audicle are C++ programs using GLUT and OpenGL for their
> interface.
> Nothing specific about Chuck. They just happen to use Chuck for their
> sound engine.
> (Or rather, Audicle is a front-end specifically for Chuck, but it's
> written in C++.)
> There's nothing about Chuck that says you have to use OpenGL. Or even Audicle.
> Personally I find miniAudicle a nicer environment than Audicle. Or
> even just Emacs.
>
> In fact after playing with it for a couple of days I'm seriously
> starting to consider re-writing some of my apps to use it for the
> audio back-end instead of my hacky C++ code. You automatically get
> good timing, OSC support, all the filters you could want, etc...
>
> Anyways my post wasn't really intended to promote Chuck, it's just
> something I've been looking at lately so it came to mind.
>
I've been doing a fairly good amount of python coding for audio
(speech) signal processing lately, so I feel like I can give my own 2
cents on the topic

 - processing a lot of data, quickly, is possible in python for signal
processing, if you are using something like numpy, which provides a
fast array package to python (think matlab, but with a real language).
 - as others have noted, python is not well suited for real time
tasks. For once, the current implementation relies heavily on dynamic
memory allocation, which makes it hard to control what happens when
memory wise. Whether this is inherent to the language itself, or its
implementation, I don't know, thi is beyond my knowledge.

I think the question is: what for ? For prototyping, I think python is
fantastic. And if it is good for signal processing, I don't see any
reason why it would not be for audio dsp. The availibility of things
like ctypes make it really easy to prototype something in pure python
from C libraries. If you want to do offline audio processing, then
again I think doing many things if not most in python may make a lot
of sense, at least if you want to do audio processing.

Could be intereseting to ask to the pypy's folks about the possibility
 of having a real time capability to python (pypy is an implementation
of python in python, with the goal to have a flexible implementation,
this making changin many key points of python "easy". For example,
they have an implementation which uses a garbage collector instead of
reference counting).

http://www.scipy.org/

http://codespeak.net/pypy/dist/pypy/doc/news.html
Received on Wed Feb 7 20:15:01 2007

This archive was generated by hypermail 2.1.8 : Wed Feb 07 2007 - 20:15:02 EET