this is a new version of AutomataUI, rewritten to be compatible with gamma and other tools. its working but not thoroughly tested and still in development.
its a simple timebased statemachine editor, which helps you to control the sequence of your project. it can be used as a non-linear timeline and an overlapping user interface, to quickly trigger scenes and events.
we use it primarly to control shows. a state can be regarded as a scene , connected by transitions.
toDo’s:
making a nuget out of it (tricky because of dependencies), i did not manage this so far aka need help here
right now automata saves its patch into a pin (see screenshot) , you load and save manually using bangs. this is not optimal and will most likely change.
Question: How to save node specific data ?
thing is, this saving method only works in vvvv gamma patch mode and not with a compiled version of your project. there are no pins to write to, when you compile. therefore i’m wondering how to make this work for everybody. any idea how to elegantly save the automata patch with every automata node in use.
write stuff to the file system and use the vvvv node ID of automata to distinguish multiple instances ? any way to keep the data inside the vvvv patch, even when compiled ?
edit: what would be really nice if vvvv gamma comes with a system like Unity3D called playerprefs. this allows saving data similar to key/value store and reading it back. and this works across all platforms and of course when the app is compiled. Unity Feature 101: Basic Saving Using PlayerPrefs | by Mohamed Hijazi | Bootcamp
I was looking at the AutomataXML output earlier today.
I’m curious if the rendering will stay or if you prefer to render the editor in Skia.
This would be interesting because one could parse that huge XML and make an Automata Object in VL. Then it would be possible to serialize/deserialize that object(s).
the editor is rendered in skia and the xml is deserialized from objects.
@amir , reading your post again, i think i don’t get what you up to. regarding rendering, is rendering in skia good or not good right now ? and why do you want to serialize /deserialize ? you actually can if you want to, look inside the automata vl lib, most of that is patched and can be modified.
Let me rephrase, if I get it currently, all Automata data is already being stored on the XML pin, right?
And the PlayerPrefs looks like an object which you could feed with the Automata data. In the Unity example they serialize the PlayerPrefs class and write it to a .json, no?
Now what I’m trying to say is we could for instance make an AutomataPrefs object and serialize that object to .xml and save it on the disk.
I will have a closer look into the automata vl.lib
@amir , no need for an extra step, its all objects and currentely serialized to xml. this can be saved to disc, yes. (i’ve tested that already) with the added difficulty that we can have multiple automata nodes in the project and each one needs to save its own data.
maybe i have to rephrase my question. i’m looking for a best practise to save node specific data. Unity3D has this best practise called playerprefs, a place to save/load project data which works everywhere (also when compiled). vvvv beta also has this best practise in form of config pins, one could save to and automatically save the data with the patch.
when i just save the automata data somewhere, how can i make sure it also works when the patch is compiled and runs on a raspi ? i’m looking for a future proofed way.
one way could be: if vvvv gamma always comes with its own sqlite database (single file), which always gets shipped with the compiled product, a place where everybody can save dynamic project data rather than writing single files to the disc.
just to clarify: if with this method you’re using the AutomataUI while developing a patch in the vvvv editor it works as expected. you can then export the patch and the automata program saved in the patch will also work in the exported application. only what will be a limit of this method is that now a user of that exported app will not be able to change the automata program anymore. so depends on the usecase.
regarding PlayerPrefs: the closest we have is a node called Persistent [System.Serialization] that just allows you to write/read a custom data type to/from disk. is this missing anything for your usecase?
either way, modeling something more closely to PlayerPrefs could be quite easily done (note to self: i think i already did that some time ago, need to dig this out) and could be a nice addition to the corelib.
aha, so this was a misunderstanding when talking about this via element. it sounded like the information saved in the pin is lost when compiling. then it is totally fine. the statemachine graph should not change in a compiled program.
but Persistent [System.Serialization] sounds interesting, definetely of use for future projects
I have this small library which uses automata internally. The framework is a separate repo and integrated as a submodule into multiple projects. It would be nice if automataUi could feature a dynamic path for the automata patch to be saved in.
i was trying to avoid saving stuff to extra files but i could give you the serialized data to a output pin, you can manage the saving yourself and load your filedata into the config pin, which already works with the serialized data
Hey @u7angel
I was wandering around on the nuget.org and noticed the VL.AutomataUI only has a vvvv tag, maybe you’d like to concider adding a VL tag as well?
it would great if you could include XML output, for saving AutomataUI layout, in the next nuget. if I can try with the current one by modifying something please explain how.
