discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] GRC taps as parameter in hierarchical block?


From: Koslowski, Sebastian (CEL)
Subject: Re: [Discuss-gnuradio] GRC taps as parameter in hierarchical block?
Date: Fri, 20 Mar 2015 10:08:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/19/2015 04:26 PM, Tom Rondeau wrote:
> In the meantime, perhaps using parameters to define other parameters isn't 
> really the right thing to
do, anyways. You are setting the default value based on the default
value of another parameter. When actually using the hier_block in
another flowgraph, that nfilts doesn't propagate through to reset the
default value of the taps parameter. So I don't think that this would
even have the desired behavior you're looking for.

GRC evaluates params in a separate namespace which is then merged with
the one holding variables and imports. While it is trivial to change
that, I must cite with Tom, params should not depend on each other.
However, your taps param should have been marked invalid.

If I understand your scenario correctly you could try one these (no
warranty):

- - if all you need is a default set of taps, use "taps or default_taps"
in your filter block and set the taps param default to "()"
- - pass a filter generator function into the block. Using
functools.partial you even preset (some) args (and standardize the call
signature) in the parent fg and then call it in the filter block
"taps_generator(param1, param2)"
- - pass the filter design call as a string and eval it. (Ugly)

Sebastian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVC+N9AAoJEIcqoDnyZkMDJOwQAKA7aNlN6J1R3un9wHFzmhld
yqLaPqVtR9S5f2I+GgmvAYSayKU7qdW8/jP6MvW8HzXmAMqwR+4+qC0yASJr+bfy
aQ19gZukxlQ0OTEgJ0Whx2qKQg0as0aIdpd5i08g/vr0Eh4m709cMPPnvkCjR9dG
zMtYkHS9a0WOQHbsgKTkwGUIolFNOvk6jS4UYYYxMJ/YOQgFf3blXgYmYN1YGec5
2k24pEOOLpr+RxhhRjbkItdap+axjijmg9pBDmghPspbHWAtw7z5jW3cAmb1GXUG
qr8WsdU/ALbigLn6KuPvTXEXv1pVzFZFAaOgrciY7McZEOjE3QZH6+KYNoUCak7D
QcuV4GWobvygUeBFmYB4au5f29tT+16KKDZpm+B54M6Oa9WFZ486HRjv1tEYAMcl
Dr1PqDtCbNJ4xsFA4Whf+71tgwY33yij1MkiQiKlAs6r5eu57gR8Xy9JPDxLLojJ
IbwGZKCN1JuZOTmaSjw2DQqLEEZ5QgPqmc9Uda8lnt9qv6Rd4Jbam0CoKraf1ATI
KO2v4aJBWOhSNyIXuwhPoA9P6fPqXeKhkgD7ZwAUQBsYwwsYqfZ6clZyhycGgMw7
2lqnx4ry0l4cxZR+VzXnkMpL0vW15vCdtRaIXZ7YaBtEvFaJCo9sSkax1+rHhCPf
9dF0ETCMhaJDp49innZ6
=FVo6
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]