a incrementally improved .fsm, may hang upon reloading it

[steph_tsf]

I guess such topic got already covered, but I ignore the related keywords for narrowing my search.

I recently made a .fsm whose architecture is special. The app displays a couple of selection boxes following a hierarchy. Such hierarchy allows choosing various activities and modalities. Such hierarchy replaces a esoteric clutter of buttons. The implementation is elegant, only consisting in simple schematics, simple front panels, dedicated to the requested activity.

All schematics miss the DS-in and DS-out (audio) components. This is because a .fsm cannot embed several DS-in and DS-out (audio) components. Consequently, on the main schematic, I've put the DS-in and DS-out (audio), for letting all "boards" to exploit the DS-in (audio), and for letting also all "boards" to feed the DS-out (audio).

For avoiding a huge mess, the master module exploits the "index" value that's outputted by the master selection box. Such index gets distributed to all sub-schematics aka "boards". There is a integer number associated to each sub-schematic. There is a integer numbers comparator Inside all sub-schematics. Only in case the index, matches the sub-schematic number, is such sub-schematic allowed to become visible. This is done by applying a logic level on the "DoIt" pin of a "Redraw" component.

All modules, aka "boards", aka schematics, visible or not, still execute. That's to avoid. We want a multiplex, not a merge. Thus, Inside each module, the schematic embeds a "signal selection" component acting like a "three state" buffer. This way, the only schematic that's allowed to output data or audio, is the one whose number corresponds to the "index" of the activity selector. Consequently, the not-selected modules, aka "boards", aka schematics won't perceive changes at their inputs (thus, such modules won't process anything), and also, their outputs will remain isolated from the rest of the world. One must remain careful with "ticks", possibly internally generated. One must block them also.

Such method allows to quickly assemble convoluted multi-mission instruments, whose front panels are kept minimal. One can rely on "tested good" modules, dedicated to the task. Nowhere can we find "if then else" code aiming at customizing the front panel. The whole thing remains exquisitely simple to conceive, and simple to debug.

This worked like a charm, as .fsm in the making. The assembly of such multi-mission instrument was so rapid, that I did it in one shot, feeling no need to reload the .fsm during the making. Finally, I saved the .fsm, prior generating the corresponding .exe.

I launched the .exe.
The .exe hang at launch.
I had to kill the .exe using the Win7 task manager (ctrl alt del).
Win7 managed to kill the .exe in a clean way. No reboot was required. I rebooted the PC, just in case.
I reloaded the .fsm, for determining where I could have been faulty.

I guess I will never know the answer, because the .fsm doesn't load properly. It hangs. The Flowstone components toolbar remains empty, and saying "wait".

One need to keep in mind that a apparently simple .fsm that one is incrementally improving, that's working like a charm during the creation process, is never guaranteed to load and lauch properly.

Attached is the faulty .fsm.

skeleton.fsm

(4.07 MiB) Downloaded 709 times

I remain interested in knowing if the skeleton structure I devised and implemented, is eventually to avoid.

I can understand that such skeleton can render the loader, quite perplex. There are so many signal dead ends. Such particularity may trigger a vast amount of retries, before everything settles down. But, even in such unfavorable context, why o why, can't the load succeed? Are there limitations, we are not aware of?

All comments welcome.

[trogluddite]

Only in case the index, matches the sub-schematic number, is such sub-schematic allowed to become visible. This is done by applying a logic level on the "DoIt" pin of a "Redraw" component.

Do you not use a multiplexer for the View connectors?...

multi_page_gui_example.fsm

(3 KiB) Downloaded 721 times

You may still need to block other inputs/outputs if there is other processing which needs to be "multiplexed", but multiplexing the Views will prevent redraws much more reliably than "disconnecting" Redraw triggers.

The Redraw components allow the schematic to send a trigger to signal "my image has changed", but there are other "hidden" redraws. For example; when there are components which overlap on the view, "background" items must be redrawn when "foreground" items are redrawn - so "background" gets a redraw even when there is no Redraw trigger. The FlowStone application also sends many "hidden" redraws to refresh the editor window, toolbox, and navigator views.

Whether the schematic crash is related to this, I cannot say. I could not see inside, as it froze FS when I tried to load it - I can only confirm that the "bug" is the same here (FlowStone 3.0.6, Windows 10).

[trogluddite]

Are there limitations, we are not aware of?

There are some limitations which are not officially documented. For example, there is a maximum number of components and connections, due to restrictions on the amount of memory which FS reserves at startup. I can't give an exact figure, because it depends which components you use, but it would only apply to extremely large schematics (hundreds of thousands of components, say).

I have seen this kind of "locking up" before with other schematics that I've downloaded from the forums (i.e. where the toolbox does not even get loaded). I haven't got to the bottom of what causes that; I suspected that it was incompatibility between different FS version, but that would not explain your inability to load your own file.

I also advise always saving schematic files with the audio driver primitives (DS/ASIO) turned off. Schematic bugs can sometimes cause the drivers to fail at load time, which usually causes a crash when it happens. And, as has been said before, if you use Beta or Alpha versions of FS, anything could happen; so they are best avoided for important work.

[steph_tsf]

I admire the simplicity of the GUI page multiplex, but in case of only doing so, each page remains unaware of the page selector index. Consequently, each page cannot drive its "three-state" isolators. Consequently, one need to pass the index to all pages, and include a integer value comparator in all pages. This is not a criticism. This is just a precision, dealing with the details. Next time it is raining I'll pass a few hours, building a better skeleton this way, taking advantage of the native GUI page multiplex component that you advised.

By the way, in case you find a can opener, please tell me, so I can try cleaning the old skeleton, in the hope that I can base on it.

I am solely running Flowstone 3.0.2 that I purchased in June 2013, that became 3.0.3 in July 2013, and became 3.0.4 in December 2013. I am thus running Flowstone ver.3.0.4. Being not a "power" user (yet?) and making no money (yet?) with my Flowstone productions, I don't feel the need to upgrade. Unless you strongly advise to do so, for easing the terrific support you are providing.

A fraction of a second before submitting the present form, a question arises in my mind. In case I don't equip the audio outputs with "three-state" isolators, do I run the risk of provoking audio attenuation when two or more "blue mono" converge to the pin of the "output" component that's sitting on the "main board" aka parent page, aka main page? If not, do I run the risk of provoking digital saturation, knowing that at a certain moment, anyway, Win7 must send fixed-point 16-bit or fixed-point 24-bit audio data to the soundcard? Sorry for such last-minute stupid question. This is of importance, as the more "pages" there are, the more the audio will get attenuated, in a somewhat unpredictable way, upon adding more "pages" each time the application gets refined, extended or upgraded.