Re: [Discuss-gnuradio] GSoC: Filter Design tool update

[Josh Blum]

On 07/23/2012 10:15 PM, sreeraj r wrote:
> 
> 
>> In next few weeks I will be adding some special filters like 
>> half-band filter to the design tool, then will proceed with 
>> integration of gr_filter_design to GRC and will try to add QA
>> tests for filter design routines wherever they are missing.
>> 
> 
>> Need any help with the GRC integration? I know there was some talk
>> about creating modules to call into, etc so the hooks into GRC
>> would be simpler.
> 
>> Let me know. Thanks! -josh
> 
> Could you please share the discussion link if there is one. You and
> Martin already gave me various hints regarding this before. Still if
> there is a standard way of doing this, that info will be really
> helpful.
> 

I didnt mean to imply that there was some kind of formal discussion tool
like a forum thread. I was just referring to these emails:

https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00142.html

https://lists.gnu.org/archive/html/discuss-gnuradio/2012-05/msg00146.html

I think that a new parameter tag would include an import statement and a
function to call. Example:

<param>
        <name>Taps</name>
        <key>taps</key>
        <value>[0]</value>
        <type>float_vector</type>
        <launcher>
          <import>from gnuradio.filter import awesome</import>
          <function>awesome.function_to_call</function>
        </launcher>
</param>

* I guess the idea would be that GRC adds a gui button the parameter
that will invoke this launcher. It then calls
awesome.function_to_call(current_param_setting) and when the function
returns, the new value is set for the parameter.

* Its not the only way to do this but that is one way to solve the
problem in a generic fashion. I think the important part vs the idea you
first purposed is that GRC does not have to know how to execute a
program, it just calls a python function, which is something that it can
easily do.

* Once such a launcher is possible, it would not only be nice to add
this to blocks with parameters that take taps. But it would also be nice
to add a new variable block to GRC that simultaneously allows the user
to use this tool, but set its output to a GRC variable. Because I think
that it will be more desirable in certain cases to set the result to a
variable.

* Another block idea, how-about a GRC block that instantiates a GUI
element that also calls the filter generation tool and sets the taps in
a callback like fashion. This would give you access to using this tool
in a live/running flowgraph!

Let me know what you think,
-josh