Hi,
First: Please pay attention and reply to the list and not to me personally.
> A suggested "improvement" to the gnuradio code base (let me know what you
> think) :
> Please keep such objects in a globally visible list (I can provide a diff if
> there is interest) so that applications such as mine can access them. UHD >
> sources and sinks are likely to be quite static as are indeed most gr blocks
> I would suspect.
What I think is that I wouldn't call that an improvement at all. IMHO
It's a horrible design ...
>> You'll have to give the instanciated uhd source block as an argument
>> of your custom block constructor and play with SWIG to make the Python
>> object be converted back to a C++ smart pointer. Have fun.
>
> It sounds quite messy and hence I had to ask this list if there was a better
> way.
Wait what ? Passing the pointer cleanly between blocks is "messy",
but polluting the global application namespace is "clean" ??? I think
we have radically different idea of what's good design and what's not
...
> I am open to any ideas. I could of course modify the gnuradio source code
> to export a global pointer but I'd love it if I could leave the core source
> code alone.
If I'm not mistaken, you can control the UHD source / sink with
message passing to change the frequency. Then your MAC just has a msg
output port connecting to the uhd message input port to control it.
Cheers,
Sylvain
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
