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. > Sylvain, if you'd like to pull it back, it's in a Github repo at > g...@github.com: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. Cheers, Sylvain _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio