DSP Robotics Support

Perfect Human Interface wrote:Should the "if" statements maybe support SSE by default? You said it is possible, maybe it is less efficient, but wouldn't consistency in such a modular environment be more important than efficiency? I'm referring to the idea that in Flowstone we operate under the assumption that using SSE is as simple as wiring a mono4 through a stream connector. It would be frustrating if people started releasing all sorts of components and it ended up a bunch of them weren't SSE compatible. How would the end-user know or find out? Especially for those who are working with less knowledge of Flowstone, both in using and writing DSP2 components, it could be an important issue.

Would it be possible to create two different "ifs," one which is more robust and supports SSE fully and predictably and one which is basic and functions as you've described?

You've got a good point there. When I started the DSPcode2 project, it mainly meant to be a DSPcode for mono, that enables several possibilities that are only mono-compatible (namely branching and looping). SSE itself was not meant to contain such features - it was meant to reduce size of loops and allow some parallel processing (by processing 4 identical operations in parallel). Above-mentioned SSE compatible "If" statement is more of a "hack". It becomes especially complicated in nested loops (when you need different number of iterations for each channel) and branching within branching. Frankly, I can't even do it at my current level of programming knowledge. There's a loot of stuff to be considered and done if such behaviour should be implemented (for example when global variable is being updated inside a function, or when data travels form one channel to another). I'm not saying it can't be done, I'm just saying it's beyond my skills at the moment, but maybe in the future... who knows.

What I personally consider the main update vs. the old DSPcode is to allow bigger customization. To combine low level features (like inline assembler) with high-level features (ifs, loops, no need to manage registers and labels) and to wrap low-level stuff into usable high-level features (declaring new functions as ASM blueprints).

Once the main work is done, I will write a manual that will describe all features (and point out all their differences vs. the "mono-channel" programming languages like C and ruby) along with several useful and clear examples (like the one I pointed out above). I will clearly point out which features are mono-only and provide poly-compatible versions (or at least examples how to mimic poly compatibility) if it's even possible.

I'm glad we're having this discussion, it gives me an idea what people actually expect from this...

Hello... DSPcode2 compiler is close to finish. I still have to make the implementation of of IFs and loops, but the function part is finished. I'd kindly ask people to start making function packs. I've written a detailed manual with several examples. Hopefully it's clear enough - feel free to edit the manual / write new one .

Why the manual does not opens in flowstone and asks for flowbotics studio?

tester wrote:Why the manual does not opens in flowstone and asks for flowbotics studio?

Because it's a .rar file not a fsm - you have to change the extension from .fsm to .rar and unpack it (there's a doc file inside).

Great stuff KG, I will make a start on a function pack

KG_is_back wrote:

tester wrote:Why the manual does not opens in flowstone and asks for flowbotics studio?

Because it's a .rar file not a fsm - you have to change the extension from .fsm to .rar and unpack it (there's a doc file inside).

My mistake. OTOH tried with zip files?

nice work KG_is_back

your code generator is really impressive

guys, I think I'm going crazy... I've finished the compiler this morning and started to make some functions for the stock pack... then I've realized that one particular peace of code works only when used using .setAdvancedCodeGen but doesn't work for any other type (.setRunCode for example). In BlueprintCode method the @inputCodes array changes to default value and I can't figure out why. There is no apparent reason why it should do that. I'm completely lost and feel helpless

EDIT: murphys law... I've found the problem instantly after submitting this post

EDIT: murphys law... I've found the problem instantly after submitting this post

had that happen too often ... but glad for it !!

RJHollins wrote:

EDIT: murphys law... I've found the problem instantly after submitting this post

had that happen too often ... but glad for it !!

I've lost count how many times I rage-quitted in this project hundreds of lines of code, handling mostly strings, arrays and hashes... what can go wrong eh? They say it's more about the journey than destination... I sincerely hope this will be fifty:fifty with the whole journey-and-destination thing and that this will become a widespread Flowstone tool. I'm near finish, I'll just add a few more functions into "factory" pack and post the beta version, so you guys can find all those nasty bugs I've left behind