On Sun, Sep 25, 2011 at 10:58 PM, Josh Blum
<address@hidden> wrote:
So there is a useful feature I think gnuradio is missing, and thats the
ability to rapidly prototype signal processing in python. It would be
great if a python block would have access to all the facilities
available to a block written in a c++ environment.
So I put together pyblock (not to be confused with those other project
by the same name). Its a stand-alone build that links against gnuradio.
https://github.com/guruofquality/pyblock
Theres a few demos: an adder, using tags, interp and decim blocks.
https://github.com/guruofquality/pyblock/tree/master/examples
The interesting thing is that the work functions just call into numpy
routines, so there is a chance that the implementations can be
reasonably fast.
I would like to be able to support history so i can implement a filter
using numpy but I am a little lacking in the basic understanding so fill
me in if you know. Suppose I have this work function:
int work(int noutput_items, gr_vector_const_void_star
&input_items,gr_vector_void_star &output_items){
const float *in = reinterpret_cast<const float *>(input_items[0]);
I am assuming history is on the input buffer.
Is the vector "in" ninput_items + history() items long? Where
ninput_items = noutput_items*/some_factor.
Whats the first index of the first item? Is in[0] or in[0-history()]?
-Josh
Josh,
This is REALLY cool, thanks!
Now, here's the question. Do we keep this as a separate project or put it into GNU Radio proper?
If you want to keep it separate and on github, we could at least clone it on
gnuradio.org and have a redmine projects page for it. Or even just a link if you don't want to worry about updating and supporting the redmine interface and feel that github gives you everything you need.
Part of me wants to put this into GNU Radio, just because it's a nice feature for developers, especially those not comfortable developing code in C++ going back and forth between GNU Radio and Python (which I've often done in the past).
On the other hand, part of me doesn't want it in GNU Radio because I don't want people to start using it as the default way of doing things, specifically, that they don't start with a pyblock and never move it into a proper C++ block. In my experience with numpy (and scipy), they are great interfaces and they are faster than using Python, but they are still much slower than they could/should be. So we shouldn't be relying on Python-level stuff for real implementations.
On the other hand (I think I've run out of hands...), this also goes a long way to solving the problem of people wanting a Matlab interface system. If you could work in using Matplotlib into your examples, people might see how much they can do in Python that replicates/replaces/supersedes Matlab for these purposes.
Again, great stuff. Let us know how you want to continue to support it.
Tom