I just had this idea and would like to know if there is any major
impediment to doing it. Could I add a little colored rectangle next to
input and output port that would change from green to yellow to red
depending on the size left in that ports buffer? I feel it would help me
narrow down sample rate problems or figuring out which blocks are slow
Would this be a relatively simple addition to the block class?
Correct me if I’m wrong, but this is what I envisioned.
From an OOT module I’ve been able to send various debug info out using
std::cout. It doesn’t matter to me if it’s configured at runetime or
compile time, because I’m sending the runtime values out. Instead of
directing things like buffer sizes and item length to stdout, I’d like
feed them up the chain to be used in GRC.
I’m not familiar with control ports, but you say something like this
be coming out in release 3.8 then?
GRC, per-se, isn’t involved in the runtime environment of the generated
python code. Making it more involved would be a non-trivial
architectural change. But, at least conceivably, one could mate-up GRC
with ControlPort in ways that are “integrated and creamy”.
But with only basically 1 person maintaining GRC, there may be more
important things on the plate…
gr-perfmonitorx is extraordinarily similar to what you are wanting, but
nothing to do with GRC. GRC can’t really do what you’re describing–
it as a tool to generate python scripts to make gnuradio graphs and