Python for DSP

Started by Max March 22, 2015
Seems that Python is catching on for some DSP work. The recent
Coursera course co-sponsored by Julius Smith III used Python rather
than Matlab.

I've searched for DSP libraries but there's kind of a confusing
jumble. Some are just using SciPy.  Does anyone know of specific
Python libs that would extend SciPy's scope?
On Sun, 22 Mar 2015 10:08:29 -0400, Max <Max@sorrynope.com> wrote:

>Seems that Python is catching on for some DSP work. The recent >Coursera course co-sponsored by Julius Smith III used Python rather >than Matlab. > >I've searched for DSP libraries but there's kind of a confusing >jumble. Some are just using SciPy. Does anyone know of specific >Python libs that would extend SciPy's scope?
Tap tap....Is this thing on? Well, I guess the deafening silence answers that question; no one is using Python! :-) If anyone is curious, I found a paper, Python for Audio Signal Processing (Glover, Lazzarini, and Timoney) that outlines some libraries. I believe there is also a code library at the Coursera site that I mentioned above, but I haven't checked it yet to find out the scope. Please check in if you find anything later.
PS: Here's a list of the Signal Processing functions in the SciPy DSP
module:

http://docs.scipy.org/doc/scipy/reference/signal.html

It looks like they've been implementing a lot of Matlab functions.
It's worth a look.

Main documentation page for Numpy (matrix and math lib) and SciPy
(everything else) here:

http://docs.scipy.org/doc/
On Mon, 23 Mar 2015 10:22:41 -0400, Max wrote:

> On Sun, 22 Mar 2015 10:08:29 -0400, Max <Max@sorrynope.com> wrote: > >>Seems that Python is catching on for some DSP work. The recent Coursera >>course co-sponsored by Julius Smith III used Python rather than Matlab. >> >>I've searched for DSP libraries but there's kind of a confusing jumble. >>Some are just using SciPy. Does anyone know of specific Python libs >>that would extend SciPy's scope? > > Tap tap....Is this thing on? > > Well, I guess the deafening silence answers that question; no one is > using Python! :-) > > If anyone is curious, I found a paper, Python for Audio Signal > Processing (Glover, Lazzarini, and Timoney) that outlines some > libraries. I believe there is also a code library at the Coursera site > that I mentioned above, but I haven't checked it yet to find out the > scope. > > Please check in if you find anything later.
No one here, at least. There's someone who comes on and mentions it occasionally, but that's as far as it goes. I'm past the age where I'm willing to learn a new language just for fun, so learning Python is low on my list of priorities. -- www.wescottdesign.com
On Monday, March 23, 2015 at 11:13:07 AM UTC-4, Max wrote:
> PS: Here's a list of the Signal Processing functions in the SciPy DSP > module: > > http://docs.scipy.org/doc/scipy/reference/signal.html > > It looks like they've been implementing a lot of Matlab functions. > It's worth a look. > > Main documentation page for Numpy (matrix and math lib) and SciPy > (everything else) here: > > http://docs.scipy.org/doc/
One thing you'll want to import is the plotting library - most use Matplotlib. There is also a symbolic math library Sympy. You may also want to check out the following page: http://wiki.scipy.org/NumPy_for_Matlab_Users Note there are different types of Arrays in Scipy (array vs matrix) and you have to be careful which one you use - depends on the type of operators you want to have. If you want to use splines (I believe) you may to use a different library for that. You may also want to look a the following page for common additional libraries http://www.scipy.org/topical-software.html Cheers, David
>Seems that Python is catching on for some DSP work. The recent >Coursera course co-sponsored by Julius Smith III used Python rather >than Matlab. > >I've searched for DSP libraries but there's kind of a confusing >jumble. Some are just using SciPy. Does anyone know of specific >Python libs that would extend SciPy's scope?
Jason Sachs wrote an article a couple of years ago, comparing Python with Matlab for Signal Processing: http://www.embeddedrelated.com/showarticle/197.php Not sure if you will learn anything new, but I mention it just in case... Stephane --------------------------------------- Posted through http://www.DSPRelated.com
On Tuesday, March 24, 2015 at 5:04:29 AM UTC+13, Tim Wescott wrote:
> On Mon, 23 Mar 2015 10:22:41 -0400, Max wrote: > > > On Sun, 22 Mar 2015 10:08:29 -0400, Max <Max@sorrynope.com> wrote: > > > >>Seems that Python is catching on for some DSP work. The recent Coursera > >>course co-sponsored by Julius Smith III used Python rather than Matlab. > >> > >>I've searched for DSP libraries but there's kind of a confusing jumble. > >>Some are just using SciPy. Does anyone know of specific Python libs > >>that would extend SciPy's scope? > > > > Tap tap....Is this thing on? > > > > Well, I guess the deafening silence answers that question; no one is > > using Python! :-) > > > > If anyone is curious, I found a paper, Python for Audio Signal > > Processing (Glover, Lazzarini, and Timoney) that outlines some > > libraries. I believe there is also a code library at the Coursera site > > that I mentioned above, but I haven't checked it yet to find out the > > scope. > > > > Please check in if you find anything later. > > No one here, at least. There's someone who comes on and mentions it > occasionally, but that's as far as it goes. > > I'm past the age where I'm willing to learn a new language just for fun, > so learning Python is low on my list of priorities. > > -- > www.wescottdesign.com
I couldn't agree more! What the hell is wrong with a simple c compiler? Is there something that Python gives us that c doesn't? Don't get me wrong, I am open to new things, I program FPGAs in LabView language even for rapid prototyping. Python doesn't hit the spot with me though.
gyansorova@gmail.com writes:

> On Tuesday, March 24, 2015 at 5:04:29 AM UTC+13, Tim Wescott wrote: >> On Mon, 23 Mar 2015 10:22:41 -0400, Max wrote: >> >> > On Sun, 22 Mar 2015 10:08:29 -0400, Max <Max@sorrynope.com> wrote: >> > >> >>Seems that Python is catching on for some DSP work. The recent Coursera >> >>course co-sponsored by Julius Smith III used Python rather than Matlab. >> >> >> >>I've searched for DSP libraries but there's kind of a confusing jumble. >> >>Some are just using SciPy. Does anyone know of specific Python libs >> >>that would extend SciPy's scope? >> > >> > Tap tap....Is this thing on? >> > >> > Well, I guess the deafening silence answers that question; no one is >> > using Python! :-) >> > >> > If anyone is curious, I found a paper, Python for Audio Signal >> > Processing (Glover, Lazzarini, and Timoney) that outlines some >> > libraries. I believe there is also a code library at the Coursera site >> > that I mentioned above, but I haven't checked it yet to find out the >> > scope. >> > >> > Please check in if you find anything later. >> >> No one here, at least. There's someone who comes on and mentions it >> occasionally, but that's as far as it goes. >> >> I'm past the age where I'm willing to learn a new language just for fun, >> so learning Python is low on my list of priorities. >> >> -- >> www.wescottdesign.com > > I couldn't agree more! What the hell is wrong with a simple c > compiler? Is there something that Python gives us that c doesn't?
Or that GNU Octave doesn't?
> Don't get me wrong, I am open to new things, I program FPGAs in > LabView language even for rapid prototyping. Python doesn't hit the > spot with me though.
I haven't taken a close look, but I'm of the same mindset. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
On Mon, 23 Mar 2015 12:53:58 -0700, gyansorova wrote:

> On Tuesday, March 24, 2015 at 5:04:29 AM UTC+13, Tim Wescott wrote: >> On Mon, 23 Mar 2015 10:22:41 -0400, Max wrote: >> >> > On Sun, 22 Mar 2015 10:08:29 -0400, Max <Max@sorrynope.com> wrote: >> > >> >>Seems that Python is catching on for some DSP work. The recent >> >>Coursera course co-sponsored by Julius Smith III used Python rather >> >>than Matlab. >> >> >> >>I've searched for DSP libraries but there's kind of a confusing >> >>jumble. >> >>Some are just using SciPy. Does anyone know of specific Python libs >> >>that would extend SciPy's scope? >> > >> > Tap tap....Is this thing on? >> > >> > Well, I guess the deafening silence answers that question; no one is >> > using Python! :-) >> > >> > If anyone is curious, I found a paper, Python for Audio Signal >> > Processing (Glover, Lazzarini, and Timoney) that outlines some >> > libraries. I believe there is also a code library at the Coursera >> > site that I mentioned above, but I haven't checked it yet to find >> > out the scope. >> > >> > Please check in if you find anything later. >> >> No one here, at least. There's someone who comes on and mentions it >> occasionally, but that's as far as it goes. >> >> I'm past the age where I'm willing to learn a new language just for >> fun, >> so learning Python is low on my list of priorities. >> >> -- >> www.wescottdesign.com > > I couldn't agree more! What the hell is wrong with a simple c compiler? > Is there something that Python gives us that c doesn't? Don't get me > wrong, I am open to new things, I program FPGAs in LabView language even > for rapid prototyping. Python doesn't hit the spot with me though.
I can't answer why Python may be better than C, but between Scilab and C I've got my own bases covered. There's a lot of PC applications being written in languages other than C, because the development can go quicker. I could see a place for Python there -- I'm just not ready to go run out and learn it yet, though. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Mon, 23 Mar 2015 16:46:19 -0400, Randy Yates wrote:

> gyansorova@gmail.com writes: > >> On Tuesday, March 24, 2015 at 5:04:29 AM UTC+13, Tim Wescott wrote: >>> No one here, at least. There's someone who comes on and mentions it >>> occasionally, but that's as far as it goes. >>> >>> I'm past the age where I'm willing to learn a new language just for >>> fun, >>> so learning Python is low on my list of priorities. >>> >>> -- >>> www.wescottdesign.com >> >> I couldn't agree more! What the hell is wrong with a simple c compiler? >> Is there something that Python gives us that c doesn't? >
Yes. The ability to get code written quickly without having to engage in continual wheel reinvention and fight with dynamic memory allocation. Having written my share of both, my Python programs are always FAR shorter, easier to read, and easier to debug (though rarely requiring it), for both trivial and non-trivial examples. I mean, God, just concatenating two strings in C opens a huge can of worms.
> Or that GNU Octave doesn't? >
Everything but math. I used to use Octave for most of my numerical analysis stuff, but god is all the stuff around the numerical analysis a kick in the teeth. Simple things like reading all the .csv files in a directory, inferring the sample rate from the file name, and graphing the resultant waveform force you into areas like file and string handling that Octave (and Matlab with it) are completely crippled in.
>> Don't get me wrong, I am open to new things, I program FPGAs in LabView >> language even for rapid prototyping. Python doesn't hit the spot with >> me though. > > I haven't taken a close look, but I'm of the same mindset.
Python is NOT the be all and end all of languages. The interpreter is slow, the runtime enormous, and when people talk about using it in an embedded environment my eyes roll hard enough to hurt. And please don't get me started on the disaster that actually distributing applications written in Python has turned out to be. But with NumPy/SciPy/Matplotlib I can do everything that I used to do in Octave as easily as I did it in Octave, plus all of the IO stuff. I can write GUI applications that talk directly to both memory-mapped and serial port hardware, run automated sweeps, analyze the data, and embed the graphs of it directly into the GUI, and still be able to manage all of it. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.