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 > On Sat, Apr 12, 2014 at 9:10 PM, Vanush Vaswani <[email protected]> wrote: > >> Interactivity, controlling flowgraph timing (start/stop), dynamic >> reconfiguration (lock/unlock), integration with Python libraries and so on. >> >> >> On Sat, Apr 12, 2014 at 9:25 PM, Activecat <[email protected]> wrote: >> >>> 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) >>> >>> _______________________________________________ >>> 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 > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
