Jeff Long

Sounds like a reasonable goal, but virtual sources/sinks are a GRC thing, and null sources/sinks are GR blocks which do not depend on GRC. I can't think of a straightforward...

We've got to find a way that there are no hardware-specific compile-time files. That defeats the runtime modularity.

In the 3.10 architecture, new hardware can be added by dropping a grc yml somewhere. Everything else is handled symbolically via the soapysdr API. There is admittedly a little Python...

Would it be equivalent to have ``` x = soapy.source("rtlsdr", ....) x.set("freq", ...) ``` or is there a reason to have the hard-coded setter?

If #5994 maintained API compatibility, this would work for 3.10.

Another report here (3.8): https://lists.gnu.org/archive/html/discuss-gnuradio/2022-09/msg00027.html

I don't know of anything in the works at the moment. You could edit the auto-generated Python for now.

Ah, I thought you were talking about a heir block. The embedded python block definitely has some limitations, and I'm not sure there's a way to fix this without completely...

Same symptom, I guess. But a heir block should work right, I think. Embedded blocks are a special hack.

It almost looks like everything works internally, but GRC doesn't know how to deal with pads whose signature can vary. It doesn't know that setting v=2 as a param means...