Dear Sir,
As an amateur I use GRC to create flow-graphs, but I see many other
users
create their flow-graphs in python by hand.
In what kind of cases the flow graphs must be coded by hand ?
(where GRC couldn’t accomplish the task)
Interactivity, controlling flowgraph timing (start/stop), dynamic
reconfiguration (lock/unlock), integration with Python libraries and so
on.
It seems that in normal usage the GRC is able to accomplish most of the
tasks without modifying the python flow-graph by hand…
On Sun, Apr 13, 2014 at 1:10 AM, Activecat [email protected] wrote:
It seems that in normal usage the GRC is able to accomplish most of the
tasks without modifying the python flow-graph by hand…
Generally, we move away from GRC when we require a lot of logic and
control
to set up the flowgraph. You might have a lot of branches to enable one
type of block over another automatically based on some user input. Other
reasons are for better UI and packaging. While we can do a lot of that
inside GRC, there’s still plenty of limitations that you can do directly
in
Python.
I tell people to work as far as you can in GRC until you hit these kinds
of
boundaries where you are then bending over backwards to make it work
inside
GRC. At that point, save the Python file somewhere and start
architecting
your program around that core.
Tom
I would also suggest to use hier blocks, as you can continue designing
the
DSP in GRC while integrating it in a Python application
Brilliant idea.
On Mon, Apr 14, 2014 at 10:04 PM, Tom R. [email protected] wrote:
Other reasons are for better UI and packaging. While we can do a lot of
that inside GRC, there’s still plenty of limitations that you can do
directly in Python.I tell people to work as far as you can in GRC until you hit these kinds
of boundaries where you are then bending over backwards to make it work
inside GRC. At that point, save the Python file somewhere and start
architecting your program around that core.
Very thorough explanation, thanks!