hi all, thomas,
is it possible to use pyext~ this way:
try: import pyext except: print "ERROR: This script must be loaded by the PD/Max py/pyext external"
try: import psyco psyco.full() print "Using JIT compilation" except: # don't care pass
import sys, math, mad, socket, urlparse, os.path from optparse import OptionParser
try: import numarray except: print "Failed importing numarray module:",sys.exc_value
class play(pyext._class): """MP3 Player"""
def __init__(self,*args):
scheme, netloc, path, params, query, fragment =
urlparse.urlparse('http://freesound.iua.upf.edu/data/19/previews/19560__11h11__itmightbeempty_p...')
try:
host, port = netloc.split(':')
except ValueError:
host, port = netloc, 80
if not path:
path = '/'
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((host, int(port)))
sock.send('GET %s HTTP/1.0\r\n\r\n' % path)
reply = sock.recv(1500)
file = sock.makefile()
mf = mad.MadFile(file)
print "bitrate %lu bps & samplerate %d Hz - ready" %
(mf.bitrate(), mf.samplerate())
def _dsp(self):
if not self._arraysupport():
print "No DSP support"
return False
def _signal(self):
self._outvec(0)[:] = self.mf.read()
#self._outvec(0)[:] = self._invec(0)
mad is for playing mp3 file. i know it's hopeless to just try to pass the buffer to _signal... but i am wonderign if it's possible: self._outvec(0)[:] = self.mf.read() maybe combined with a while.
if not, then there's only readanysf~ for playing distant mp3 file, but it's not working for me with a long url ('http://freesound.iua.upf.edu/data/19/previews/19560__11h11__itmightbeempty_p...') don't know why...
or maybe there's another solution? pat
Le vendredi 12 octobre 2007 à 13:11 -0400, patrick a écrit :
d with a while.
if not, then there's only readanysf~ for playing distant mp3 file, but it's not working for me with a long url ('http://freesound.iua.upf.edu/data/19/previews/19560__11h11__itmightbeempty_p...') don't know why...
have you tried http://tinyurl.com?
++ O.
hi thomas,
i tried it, but it's not working.
is def _signal(self): looping by itself? if not can i plug a while True:?
pat
hi,
what about using gstreamer via pyext. here's a simple "playbin" that auto-detect and connect to oss, alsa, jack for playing mp3 file over http.
WITH JACK: when clicking on [playpreview], pd disconnect and disappear from the client list. GStreamer got in and play the mp3 file. i tried [detach 0-1-2] with no success. anyone knows how to keep pd while GStreamer play the mp3 file?
WITH ALSA: since alsa can have only 1 client - GStreamer is not able to play the mp3 if compute audio is on. but it's working when turning compute audio off and clicking [playpreview] again.
try: import pyext except: print "ERROR: This script must be loaded by the PD/Max pyext external"
try: import pygst pygst.require("0.10") import gst except: print "ERROR: You need pygst (gstreamer)"
class preview(pyext._class): # number of inlets and outlets _inlets=1 _outlets=0
def playpreview_1(self,a):
print("Playing preview")
player = gst.element_factory_make("playbin", "player")
player.set_property('uri',
"http://freesound.iua.upf.edu/data/40/previews/40563__genghis_attenborough__S...") player.set_state(gst.STATE_PLAYING)
Hallo Thomas !
Signal support for py/pyext is really experimental and i don't recommend it at all, since it's also inefficient cpu-wise.
I am just curious: what is so slow ? (I did not look into the source ...)
I use also python for offline computation (not with pd yet) and it is quite fast - so is the interface to pd the problem ?
LG Georg
Hi Georg,
I am just curious: what is so slow ? (I did not look into the source ...)
I use also python for offline computation (not with pd yet) and it is quite fast - so is the interface to pd the problem ?
To my experience python is quite fast, when the underlying C components do most of the work (like with pyode, numpy, etc.). The C-python interpreter can't be called fast on the other hand, at least compared to C/C++. If you do DSP processing using Python statements (not numpy) it's really a waste of cpu.
greetings, Thomas
Hallo!
To my experience python is quite fast, when the underlying C components do most of the work (like with pyode, numpy, etc.). The C-python interpreter can't be called fast on the other hand, at least compared to C/C++. If you do DSP processing using Python statements (not numpy) it's really a waste of cpu.
Of course one has to use numpy, scipy and all that ... They use quite optimized BLAS/LAPACK algorithms, which should be faster than pure pd - but I never tried the pd-numpy DSP combination.
LG Georg
On Tue, 16 Oct 2007, Georg Holzmann wrote:
Of course one has to use numpy, scipy and all that ... They use quite optimized BLAS/LAPACK algorithms, which should be faster than pure pd - but I never tried the pd-numpy DSP combination.
No, the main reason for the speedup is not the use of optimised algorithms, it's simply the fact that GCC optimises calls and loops much more than pd does, because pd doesn't optimise at all.
every time you send a message, pd looks up the connection-list of your outlet, to find each receiver. For each receiver, it looks up the class, and in that class it looks up the anything-slot, and/or the float-slot or the symbol-slot, and if you use a named method, it goes through a linked-list of method-slots.
If you add up two arrays of 240 rows by 320 columns by 3 channels, that's 230400 additions, but because you have to manage counters and such it's triple or quadruple or worse, in number of messages.
a simple program compiled with GCC (even without any optimisation option) doesn't do the repetitive lookup because it was decided in advance that it wouldn't change and GCC looked it up once and it was over.
For a patch that tries to do float operations as fast as possible, that is still, most likely, the single biggest execution time saver, more so than SIMD, SMP/hyperthreading, ... and I would believe that BLAS/LAPACK-specific optimisations would be only for really special operations that I very rarely think about using when patching in pd.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Tue, 16 Oct 2007, Thomas Grill wrote:
To my experience python is quite fast, when the underlying C components do most of the work (like with pyode, numpy, etc.). The C-python interpreter can't be called fast on the other hand, at least compared to C/C++. If you do DSP processing using Python statements (not numpy) it's really a waste of cpu.
Let me just add that the same pattern happened within the pd world: unoptimised interpreter takes time to get one step done, so the answer is to make it so that less steps are needed. After all, that's why you made Vasp and that's also why I made GridFlow.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Hello Thomas,
I'd like to ask a related question: is it possible to use the SndObj library via pyext~ (via the python module for SndObj)? I never tried it because signal processing with pyext is too inefficient, am i right?
... and thanks a lot for all the work on pyext, it's really a very handy tool, I use it a lot!
Hans r
At 16:02 14/10/2007, you wrote:
Hallo Thomas !
Signal support for py/pyext is really experimental and i don't recommend it at all, since it's also inefficient cpu-wise.
I am just curious: what is so slow ? (I did not look into the source ...)
I use also python for offline computation (not with pd yet) and it is quite fast - so is the interface to pd the problem ?
LG Georg
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list