Credits: Christian Engler // wirmachenbunt
this is a visual finite state machine editor with built in finite state machine.
You want bulletproof logic ? You better use the automata node! Well, that's what bjoern told me a couple of years ago. And he was right. If your patch becomes more and more complex, more and more bugs turn up due monoflop, delay, flipflop and framedelay madness. It's much easier with a statemachine.
But since it is probably no fun writing quadruples, it makes sense to introduce a visual editor.
So here it is. Inspired by bjoern's "Timer" concept, transitions not only last a frame but can have a configurable duration. Quite useful for any animated user interface project, where animated transitions should be in sync with your logic.
Transitions can be pingpong, meaning they can be bi-directional. States on the other hand have a duration as well, blocking any outgoing Transition for a certain amount of time.
More rules are in the help patch.
And let's not forget, Automata UI is inspired by http://qfsm.sourceforge.net/.
we (wirmachenbunt studio) use the plugin in 12 projects right now, and it made our vvvv patcher life a lot more pleasant. hence we hope it can help you too.
an application video will follow...
The plugin is released under a similar idea of licence like vvvv. It's free for non-commercial use. If you need a commercial license, refer to http://wirmachenbunt.de/automata-license-buy
HALL OF FAME
Thanks to Manuel, Daniel, sebl, readme and mbox for acquiring a license. This helps a lot !
Very useful, good job!
dear mother of dog this is what i need in my life,
does the visual editor use the same thread as vvvv? should i be worried about performance?
@stix, check the debug mode and see how many ticks the node eats. close to nothing ;)
@bjoern, no library involved apart from Newtonsoft.Json to save the graph as JSON (which i will dump with the next release). so yeah, from scratch i did.
concerning hierachical state machine, i guess we need to discuss that in person to get a picture of the advantages/use cases and how they can be visualized.
thanks, this is great!
Awesome! Thanks a lot!
re hsm: I did some initial testing with a hsm plugin using stateless a couple of years ago and have had the plan to do something more proper since then and possibly even an editor (test used custom text dsl/parser). Unfortunately my time for doing any serious development has been very limited and haven't been able to squeeze it in yet.
Any hierarchical state machine (HSM) can be expressed as a regular finite state machine (FSM) but with a HSM you can make it a lot simpler with less states and transitions because you have nested states and a transition/action will happen if it's either handled by a leaf state itself or any of it's parents.
A reference visualization is proved by the UML standard: https://en.wikipedia.org/wiki/UML_state_machine
Posted a screenshot before but I guess nobody saw it (?): root-190#comment-220133
Finally! Thank you :) Very nice user experience.
Most likely one won't need it for the typical car show exhibit we are all so fond of.
But think of a more complex iot-type-situation, e.g. a concept car with a lot of embedded devices, sensors, buttons, touchscreens, motors and whatnot simultaneously talking to and managed by a central "vvvv-hub".
@beyon / Stateless
There is a GUI for Stateless / Visual Studio called Stateless Designer. It currently also only supports FSM though.
Ah and while we are at it, also a nice thing supported by stateless and explained here are guard clauses.
@beyon and bjoern. it's all interesting to read. concerning hierachical state machine you can use multiple instances of the node in your patch.
regarding "guards" i quote something from the link
not sure if this is a needed features. i'll probably keep it as "simple" as it is but thanks for the input.
No more thousands counter switch delay = monoflop framedelay etc ! ! ! !
vvvvow! This is great!
minor bug in combination with latest alpha. the json from the helpfile won't load.
just reset the node by Alt+right clicking, that's it...create your graph as usual and save it.
will be fixed in next release.
Christian this look really sweet. The only thing I'd miss to want to adopt this over the native node is being able to run multiple state machines. Is this possible or on the roadmap at all? Just mean multiple instances, they all have the same state graph.
@everyoneishappy, not sure if i understand u right. we're not talking about a spreaded automata right ? because multiple instances you can have. each automata graph is saved per node instance.
in case you copy your automata node and edit the new graph, you might need to trigger a transition at least once to update everything since the node behaves as lazy as possible to save cpu cycles.
does this answer your question ?
@u7angel yes I do mean spreaded automata. You said that much more clearly then I did.
@everyoneishappy, it will come
i was talking to many pro patcher and this was the most popular question " is it spreadable". on the contrary, when i asked how often do you use a spreaded automata basically only one guy did it once, years ago :)
anyway, it's almost on top of the todo list
@u7angel good to know. That's kind of funny, I can imagine "is it spreadable" being a popular question regardless of what it does. I can't say I've needed that before, but am about to embark on a project that does
i have used spreaded automata a couple times.
one particular useful case was handling 20 touch points with a single automata.
that makes 3 spreaded automata users :)
next release will have it.
Is there around some sort of tutorial on using it?
Looks great but never worked with automata
@parabola http://www.programmingbasics.org/en/beginner/fsm.html should explain the concept. You can find more stuff if you google 'finite state machine'
It's often very useful anytime you have something that should have different modes of behavior (which are what the states are).
@parabola. i will make a tutorial video. october/november
there are different use cases.
i usually use one central automata, controlling my whole vvvv project. telling each subpatch in which state (aka scene) i am and disable or enable subpatches/nodes according to the active state.
in application that means you send the current state string and everywhere else you check the string with =(string) aka "does this string equal the one which i'm waiting for here" hence enable/disable the connected nodes.
but where is bezier curves for transitions? love and will miss them
hey bo, i'll put bezier lines on the wishlist.
I really like this!!
Is there any way to tidy the transition lines? I'm making quite a complicated patch and its getting quite messy.
hello sam, bezier transitions are in the making and will be delivered until the node festival
can you provide a screenshot or a patch. would be interesting how complex your statemachine is.
and remember, you can use spreaded and multiple automata nodes to cluster your logic.
Sure, let me just tidy my patch a little.
I never knew you could cluster the automata nodes. Would you be able to explain how to do that? (im new to this)
i meant you can use several automata UI nodes , interacting (triggering) each other. hence you don't have a big graph within one automata but distributed to more than one graph.
i bet the logic can be split into parts/tasks, right ? you don't need to see all at once.
and one hint, you can try to create abstract logic, rather than putting content into your logic. so instead of having states like topic01, topic02, topic03 ... you just have one state named topic. and then handle the selection outside of the statemachine.
anonymous user login