Hi Greg, :) been biting my tongue long enough, and I think there's a metric ton of consensus to be applied here:
So, yes, everyone I've ever talked to would love GNU Radio to be more useful in fully usable applications. And: everyone, including me, hates the fact that setup, getting started and doing the first useful thing are quite a hurdle. Furthermore, none of us thinks you're nuts :) I'm not sure what you refer to when you say "production system"; I personally do think GNU Radio's primary purpose is being a library to do your SDR processing, and that library integrating itself greatly in a non-obstructive way as component in bigger applications. I also think that we're not doing a great job at that – it's really not that we see a load of applications where GNU Radio isn't the central part, instead of e.g. the user interface being more of a periphery to GR. The most visible actual application that the GR project "produces" is pretty certainly GNU Radio Companion – and I think there's good reason to make that as polished, clean and easy to use as possible. We need more prominent examples of well-working GRC flow graphs, too. What I really think is missing most is a good-practice approach and a popular example of how to design a flow graph in GRC, and use it to do something cool – gr-air-modes' modes_gui comes to mind, but I think that has reached a certain age and might need a facelift, and maybe a bit of a different approach here and there on connecting GUI, logic and GR-based processing. It's a great piece of software (kudos to Nick for writing it!), but it was clearly written by someone who loves SDR and understands GR very well, rather than by someone who uses one of the popular application development frameworks (be that Qt/QtCreator, Visual Studio, Android Studio, Node.js/Django/Ruby on Rails/…(whatever is popular with the web these days)) and integrates a signal processing backend into a great frontend that they designed first. The very same goes for best-practice guides on what we've talked about before – there's a load of data scientists, physicists, … that would love to have a great signal processing framework that integrates easily with R/Hadoop/paraview/SPSS, but neither does the project as is offer any of these interfaces, nor a guide on how to write one, nor am I aware of any more or less universal adapter. I think it's worth promoting Tim's Theano / TensorFlow interfacing blocks – they do exactly that: being an easy-to-use adapter between something non-SDRy people experts of a different field (in this case: DNNs) are proficient with and GNU Radio. To my shame, I haven't worked with those. What I personally, but I haven't discussed that so far, don't think is that we should be selling GR as an application itself – to me, it's a set of building blocks and tools to build good DSP/SDR applications. Much like noone sells Android Studio as a user application. I do see your point that GRC has really become that: something that people that might not be overly DSP-experienced or even computer-savvy can use. I'd actually like to hear what Sebastian and co would have to say about that, since I definitely haven't worked on GRC anywhere near to comparable as much, but it might actually be worth considering to more clearly make a distinction between GRC and GR. I really think this is an interesting direction – I think if we came up with a few /concrete/ ideas on what to put on the GRC ideas page for this, we'd help the project the most right now; mentoring org application deadline is Thursday. Best regards, Marcus On 02/05/2017 12:25 AM, Gregory Ratcliff wrote: > Greetings all, > > I suspect Marcus will answer this, but a discussion might be worthwhile. > > There seem to be two areas within this most fantastic system that I see some > evolution (and SOC might help): > > 1. It seems gnuradio is being used for what it is, rather than a toolset to > create something to use. Hopefully, this makes sense, but I can see that > over the next few years gnuradio should morph into an actual production > system, that draws in _users_. I’m sure many of you know what I mean. > > 2. Because of the above class of users joining the gnuradio community, there > will more and more people will expect it to work, without issues. It seems > like a concerted investment less complexity to build a running system. I’m > not sure what that means, but I suspect a few of you have some interesting > and disruptive ideas that could greatly simplify the build process but not > hurt performance much. > > Or…I’m nuts. > > Greg > Nz8r > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
