On 09/05/2011 2:25 PM, Michael Dickens wrote:
I often use GRC for simple tasks -- it's a LOT faster than writing Python scripts, and it
"just works" for these tasks. Admittedly, these are simple -- such as reading
a file of audio data, adding in gain, and then both displaying a waterfall FFT and piping
the data to audio out. I do agree that for any cutting-edge project what you write is
true, but if GNU Radio accumulates blocks over time GRC will eventually fit the needs of
that 90+% I keep talking about. Of course, that ~10% will always remain, as they are the
cutting edge folks.
There's a growing expectation that Gnu Radio exists to provide
functional blocks for *all parts* of your communications system. I
think that's
a flawed model, and flies in the face of sound modularity
principles. There's an expectation that Gnu Radio handle "everything",
and I just
don't think that's a good model. Gnu Radio, to me, is a DSP engine
that happens to live on a general-purpose compute platform. But it has
become "sullied" over the years with "other stuff" unrelated to
strictly-signal-path problems. Attempting to shoe-horn "stuff" that isn't
strictly signal-path oriented into Gnu Radio will cause both
unnecessary bloat in the codebase, but more-importantly, it will cause
people
to suffer grief in that they're trying to use the wrong paradigm to
solve the not-strictly-signal-path parts of their "solution".
True, but it's an enormous class. Maybe I'm too limited, but I cannot think of
a communication algorithm that can't be implemented graphically in GRC, somehow
(or the equivalent, via some combination of a data-flow graph and text command
line such as provided by Python).
See above. The problem is that people want the Gnu Radio signal-path
paradigm to solve problems that aren't necessarily directly signal-path
related. Strictly speaking, for example, none of the GUI stuff
should be in Gnu Radio proper at all. But it's awfully convenient. The
thinking that
lead to non-signal-path processing inside Gnu Radio is, I would
assert, a strong reason for people finding it "wanting"--they naturally
expect
that it does "everything". Which it can't. Hmmm, I wonder if a
flow-graph is Turing complete? Another example: HTML. HTML can be used
to solve a vast number of problems, and indeed rich "applications"
have been constructed using HTML. But (at least early versions of) HTML
isn't Turing complete--it's not a complete programming paradigm, and
so much functionality must necessarily be implemented outside of
it. I would assert that Gnu Radio is in the same category--it's a
paradigm for managing mathematical data-flow. So, when you have a problem
that falls outside of that model, you have to ask yourself: is it a
flaw in the model, or a flaw in my reasoning about the applicability of
the model
to my application? From what I've seen on the list over the last
several years, a goodly chunk of "heartburn" on the part of newbie users is
due to imperfect understanding of the model, and incorrectly
assigning functional pieces to the flow-graph model.
True, but that's OS-dependent and a nuisance. Why not the dual-license
approach -- one as GPL and another that allows for local IP (the LGPL would
probably suffice)? Again I don't know if the FSF would allow it, but there are
plenty of potential end-users who would benefit from this model. - MLD
I'm not an expert on licensing issues, which is why I've avoided them in
the couple of small-scale commercial systems I've done with Gnu Radio as an
underlying "engine".
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio