# GRC vs python flow-graph by hand **URL:** \ **Category:** GNU Radio\ **Created:** [April 12, 2014, 1:27pm UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410 "2014-04-12T13:27:31Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\ **Post date:** [April 12, 2014, 1:27pm UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/1 "2014-04-12T13:27:31Z")
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) ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [April 12, 2014, 3:12pm UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/2 "2014-04-12T15:12:05Z")
Interactivity, controlling flowgraph timing (start/stop), dynamic reconfiguration (lock/unlock), integration with Python libraries and so on. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [April 13, 2014, 7:12am UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/3 "2014-04-13T07:12:46Z")
It seems that in normal usage the GRC is able to accomplish most of the tasks without modifying the python flow-graph by hand… ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [April 14, 2014, 4:05pm UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/4 "2014-04-14T16:05:52Z")
On Sun, Apr 13, 2014 at 1:10 AM, Activecat [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [April 15, 2014, 1:44am UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/5 "2014-04-15T01:44:08Z")
I would also suggest to use hier blocks, as you can continue designing the DSP in GRC while integrating it in a Python application ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [April 15, 2014, 6:17am UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/6 "2014-04-15T06:17:07Z")
Brilliant idea. ---
**Author:** ![activecat\_k](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c57346/32.png) [@activecat\_k](https://www.ruby-forum.com/u/activecat_k)\ **Post date:** [April 15, 2014, 6:21am UTC](https://www.ruby-forum.com/t/grc-vs-python-flow-graph-by-hand/240410/7 "2014-04-15T06:21:15Z")
On Mon, Apr 14, 2014 at 10:04 PM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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!