3 Feb
2007
3 Feb
'07
1:28 p.m.
Greetings,
I've been studiyng python and some things are not that clear:
1- Is python too slow to efectivelly communicate with Jack? PyJack did not
seem to work right, so i tried PySndObj's JackIO object. It did not behave
as good as with connection with ALSA.
(btw, I could not acess lots of objects in the SndObj library (like Ocil,
Rand, while acessing normally Oscilli and Randh...) Does anyone know why?)
2- Python comes with the ossaudiodev module for communication with OSS; Alsa
is compatible so it works. Shuld one use this module or use the pyalsasound?
3- pySonic - pySonic the wrapper for the FMOD sound library. but it is not
opensource... is there a standard library for sound processing in projects
like ardour.
4- Are any differences between 'r' and 'rb'; 'w' and 'wb'
in:
wave.open('file', 'r') wave.open('file', 'rb')
wave.open('file', 'w') wave.open('file', 'wb')
??
5- I found pySonic, that seems good but it is not open. MusicKit and
PySndObj and omde. Ow yeah, and Pygame. Can anyone expose ihre personal
experience and explain why?
Please be nice,
Claire
5 Feb
5 Feb
6:28 a.m.
On Sat, 2007-02-03 at 16:28 -0200, Silver Rock wrote:
I've been studiyng python and some things are not
that clear:
1- Is python too slow to efectivelly communicate with Jack? PyJack did
not seem to work right, so i tried PySndObj's JackIO object. It did
not behave as good as with connection with ALSA.
Depends on what you mean. Writing the actual process() callback in
Python is probably not a good idea, not as much because of the speed
(although you probably wouldn't want to use Python if you want to
squeeze as much processing as possible out of the computer) but because
of the unpredictability caused by the builtin garbage collection and
memory management. Then again, I'm no Python expert. Maybe it's possible
to tweak the interpreter so it can run in hard realtime.
4- Are any differences between 'r' and
'rb'; 'w' and 'wb' in:
wave.open('file', 'r') wave.open('file', 'rb')
wave.open('file', 'w') wave.open('file', 'wb')
'r' opens a file in text mode, 'rb' opens it in binary mode. On
UNIX-like systems there is no difference. I don't know if Python is
clever enough to always open a sound file in binary mode on systems
where there is a difference, but it can't hurt to add the 'b' anyway.
--ll
1:24 p.m.
On Mon, Feb 05, 2007 at 12:26:09PM +0100, Lars Luthman wrote:
On Sat, 2007-02-03 at 16:28 -0200, Silver Rock wrote:
Highly doubtful. Python is fantastic for lots of jobs. This isn't one of
them.
--
Paul Winkler
http://www.slinkp.com
I've been studiyng python and some things are
not that clear:
1- Is python too slow to efectivelly communicate with Jack? PyJack did
not seem to work right, so i tried PySndObj's JackIO object. It did
not behave as good as with connection with ALSA.
Depends on what you mean. Writing the actual process() callback in
Python is probably not a good idea, not as much because of the speed
(although you probably wouldn't want to use Python if you want to
squeeze as much processing as possible out of the computer) but because
of the unpredictability caused by the builtin garbage collection and
memory management. Then again, I'm no Python expert. Maybe it's possible
to tweak the interpreter so it can run in hard realtime. 
3:18 p.m.
Highly doubtful. Python is fantastic for lots of jobs.
This isn't one of
them.
Python isn't so good at real-time audio jobs, but I think it would be
pretty decent as an audio "control" language. Using it to specify
networks of C-code unit generators that run indepedently, then
fielding OSC/MIDI messages, etc., changing parameters.
I guess there are a lot of languages that do this kind of thing. Snd
is an example of a Lisp-like language for these tasks. SuperCollider
is pretty nice, and definitely worth exploring.
However, for sample-level control, you want C/C++, for example with
STK/RtAudio, or a sound language like Csound. Lately I have been
exploring Chuck, which so far seems fantastic. The time-based control
it gives you is really simple and nice to work with.
I think a good project would be to write a Python interface to a Chuck
VM. Use Python to program a GUI which modifies variables of a Chuck
run-time.
Anyways, some things to think about. As Paul said, Python can do lots
of things, but real-time audio is not one of them. Right tool for the
job, and all... but you have lots of tools available. I recommend
exploring them.
Steve
4:43 p.m.
On Mon Feb 05, 2007 at 03:07:05PM -0500, Stephen Sinclair 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?
Highly
doubtful. Python is fantastic for lots of jobs. This isn't one of
them.
Python isn't so good at real-time audio jobs, but I think it would be
pretty decent as an audio "control" language. Using it to specify
networks of C-code unit generators that run indepedently, then
fielding OSC/MIDI messages, etc., changing parameters.
I guess there are a lot of languages that do this kind of thing. Snd
is an example of a Lisp-like language for these tasks. SuperCollider
is pretty nice, and definitely worth exploring.
However, for sample-level control, you want C/C++, for example with
STK/RtAudio, or a sound language like Csound. Lately I have been
exploring Chuck, which so far seems fantastic. The time-based control
it gives you is really simple and nice to work with.
I think a good project would be to write a Python interface to a Chuck
VM. Use Python to program a GUI which modifies variables of a Chuck
run-time.
Anyways, some things to think about. As Paul said, Python can do lots
of things, but real-time audio is not one of them. Right tool for the
job, and all... but you have lots of tools available. I recommend
exploring them.
Steve
5:23 p.m.
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.
Steve
7 Feb
7 Feb
9:57 a.m.
On 2/6/07, Stephen Sinclair <radarsat1(a)gmail.com> wrote:
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
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.
11:06 a.m.
On Wed, Feb 07, 2007 at 11:57:10PM +0900, David Cournapeau wrote:
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.
Well, the language itself is highly dynamic, you can rebind pretty
much anything to any type of object at any time, so the runtime has to
be pretty flexible.
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".
It's not just flexibility, they also want to make things much more
optimization-friendly. It's definitely an important project in the
python world, but frankly a lot of what they are doing is way beyond
me :-)
I suspect if "realtime python" is even possible, there would have to
be some restrictions to get things realtime safe... which would still
probably be pretty useful :-)
Maybe something like the "restricted python" they're using to
implement a lot of pypy?
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#restricted-python
--
Paul Winkler
http://www.slinkp.com
5 Feb
5 Feb
8:36 a.m.
If you are contemplating a lot of audio synth/dsp tasks using python, you
might want to take a look at RTcmix -- you can build it with a python
front-end:
http://rtcmix.org/
open-source, cross-platform of course!
Disclaimer: I don't use the python option myself, but several of the
other RTcmix developers use it almost exclusively.
brad
http://music.columbia.edu/~brad
On Sat, 3 Feb 2007, Silver Rock wrote:
Greetings,
I've been studiyng python and some things are not that clear:
1- Is python too slow to efectivelly communicate with Jack? PyJack did not
seem to work right, so i tried PySndObj's JackIO object. It did not behave
as good as with connection with ALSA.
(btw, I could not acess lots of objects in the SndObj library (like Ocil,
Rand, while acessing normally Oscilli and Randh...) Does anyone know why?)
2- Python comes with the ossaudiodev module for communication with OSS; Alsa
is compatible so it works. Shuld one use this module or use the pyalsasound?
3- pySonic - pySonic the wrapper for the FMOD sound library. but it is not
opensource... is there a standard library for sound processing in projects
like ardour.
4- Are any differences between 'r' and 'rb'; 'w' and 'wb'
in:
wave.open('file', 'r') wave.open('file', 'rb')
wave.open('file', 'w') wave.open('file', 'wb')
??
5- I found pySonic, that seems good but it is not open. MusicKit and
PySndObj and omde. Ow yeah, and Pygame. Can anyone expose ihre personal
experience and explain why?
Please be nice,
Claire
6380
days inactive
6384
days old
linux-audio-dev@lists.linuxaudio.org
8 comments
7 participants
participants (7)
-
Bradford Garton -
carmen -
David Cournapeau -
Lars Luthman -
Paul Winkler -
Silver Rock -
Stephen Sinclair