DSP Robotics Support

I think the biggest mistake you do when you draw a flow chart is that not considering the element of clarity and attention to detail. Every symbol has a meaning. While it may seem convenient to use a process symbol for everything, this could end up confusing the reader. To get a better understanding of what symbols are relevant when reading up on what each object is all about.
If your flowchart is connected to another flowchart, then instead of putting it in just one page, it is best that you connect it via a circular node to the flowchart on a different page.

I didn't even think about these mistakes before I read about this. If you like to know more about the mistakes we do when drawing a flow diagram check out this article. They also offer free templates to draw flow charts. https://creately.com/blog/diagrams/part-1-15-mistakes-you-would-unintentionally-make-with-flowcharts/

it seemed to me that flow draws diagrams much more flexible, besides, it is easier to create and work later, you can implement elements right away!

DigiTonix wrote:it seemed to me that flow draws diagrams much more flexible, besides, it is easier to create and work later, you can implement elements right away!

I think, for the purposes of this discussion, that the problem with "flow-charting" using FS is that FS is inherently bottom-up rather than top-down. You start connecting primitives/modules together, then enclose the result into a larger module, but (AFAIK) working in reverse is not as convenient.

(If the following widget exists, ignore me...I'm relatively new to FS and don't spend nearly enough time playing with it.)

What's needed is an empty black-box meta-module: something you can define the inputs to and outputs from without defining anything inside ahead of time, then go back and populate the missing functionality later. I suppose you could use an empty Ruby edit box with nothing but inputs, outputs, and comments, but there's the issue of cleanly replacing it with something else without losing its connections to the outside world.

I don't quite understand what the problem is, you can just use empty inputs and outputs, also if you need an empty Streamin-streamout you can do that too.
I don't think it's necessary to create a black box.)
If you need to have a permanent prototype, with mutable code, you can just make an empty plugin with ready-made buttons and so on, as many do, and those who do not work on Flow, this practice is applicable to everything, I think.

If you mean, switching between different types of streams is also possible, however, you should have ready-made elements in the stream, otherwise it is useless.

And also the use of separate templates for design, for code and other elements is always more convenient, there is no need to store socks and chicken in one box, this is IMO

Perhaps I understand you so, then please give an example where this can be used. Maybe the black box is not so bad)