discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block fo


From: Nick Foster
Subject: Re: [Discuss-gnuradio] gr-fosphor : New RTSA-like visualization block for GNURadio using GPU acceleration
Date: Wed, 30 Oct 2013 08:16:17 -0700

On Wed, Oct 30, 2013 at 1:28 AM, Sylvain Munaut <address@hidden> wrote:
Hi Nick,

> I've added basic sample rate awareness to gr-fosphor via constructor
> parameters and a set_rate() call. The GRC blocks now take a sample rate
> parameter as well. The sink also creates an appropriate legend (kHz, MHz,
> etc.) and applies it to the plot. I've tested it with WX, Qt, and GLFW
> versions of the sink.

Nice, but unfortunately I'm working on my own version of this.

I wasn't really happy with the current set_range. So I'm doing a bit
of refactoring. Basically the cl_state and gl_state struct will be
kept around for strictly CL/GL stuff but most method will get the full
fosphor struct as argument and I will put shared stuff and things not
strictly CL/GL there. For example the sample rate is useful in CL to
dynamically adapt the batch size and the time constants of fading to
ensure low latency in low bitrate case and performance in high bitrate
cases. And there is some similar stuff happenning with other types of
set/get I wanted to put in so I decided to do the refactor first.

Great! Glad to hear it. You might still take a look at the changes to gl.c, as they're orthogonal to your reorganization and it adds a nice autoranging sample rate text and legend. I agree putting everything in a large struct is the C-ish way to do things.



> Sylvain, if you'd like to pull it back, it's in a Github repo at
> address@hidden:bistromath/gr-fosphor.git. I've also added a CMake check for
> the Python OpenGL bindings, as I somehow managed to not have them installed
> on my new machine.

Interesting. Did that actually prevent build ? What was the symptom ?

A choice I've made (albeit a possibly questionable one) was to only
check for things required at build time.
For example, I don't check you have WX Python installed either ... if
you don't the import will fail in python but be caught and the sink
will just not work but shouldn't prevent using the others and if you
want the WX one, just install the dependencies afterwards and no need
to rebuild gr-fosphor.

That's fine. Really it was just a matter of a poor user experience -- when the Python OpenGL bindings aren't there, the WX import fails in __init__.py, and all the user sees is "no block named wx_core_c". Perhaps a better failure message in __init__.py is all that's needed.

--n
 


Cheers,

    Sylvain


reply via email to

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