Forum

Storing and setting paramters

Can anyone recommend a good way to edit, store and recall parameters?

I need a flexible expandable way to save patch parameters edited from a gui.

It seems like xml (and the xelement nodes) might be the way to go.

Any advice?

JSON… no text …

why JSON?

also, the main thing I’m struggling with is how to edit parameters. I can build a data hierarchy with xml easy enough, that establishes the parameters available, but I’m not sure how to then edit those from another location (eg the gui patch.

This is like a problem I have a lot in vvvv, the inability to have global variables which can be set from multiple locations, rather than just whatever is currently connected by the patch cable.

what u talking about is made with S R advanced nodes, but nobody really using them due to complexity in the end… E.g. u have one module that sends some values getting overwritten by another module u’r not epxecting to work at that time and etc…
the S/R advanced nodes also have framedelay inside

thats why I made Antenna and Radio for Message: sites/default/files/screenshot1405475819.png

Antenna is like a S, but all Spreads of all Antennas that have the same Address will be bunched together for broadcast, and any Radio will receive all of them next frame.

the “store and recall” is done easy enough in the Message (Split). All the helper plugins allow for quite complex handling of Messages, saving stuff to json is very easy, there are nodes for ID-based Caching and Storing as well.

Messages are not a continuously repeated flow of more or less the same data (as in S and R), they rather follow the concept of sending the message only in case updates are necessary.

Beware: This makes them somewhat clumsy when dealing with patches that are not evaluated (because incoming Messages will not be evaluated inside the patch as expected).

This can be done with the Store (String) node. I use it to save everything to a simple textfile, comma-seperated. Each line is a different preset, so I can add, delete, update and recall presets of all the data.

Getting the Store node to work nicely with multiple S+R nodes is a bit of a pain, but I managed it in the end. I am on the Mac right now, so cant post a screenshot.

Basically you need to have all your data pass in and out of one large spread of data. The preset store and recall mechanism then sits in the middle of it. Another spread of the same size just holds the names of the variables. These will also be used to (semi)automatically create S nodes with the variable as the send string.

Anyways, it was quite a long process to get it to work, but understanding all the pins of the Store node is central. You will have to introduce Framedelays eventually and thats when things get complicated. I found running vvvv in ultra slow-mo-mode (setting vvvv to 0.5fps - the lowest possible value) you can actually check what happens in each frame and that can be really helpful sometimes.

XML always seemed way too difficult to work with in vvvv.

Using a database server seems like a good idea, but might be not worth all the setup time for something rather simple like storing and recalling a few values.

I’ll see if I can distill down a workable version of what I am using tomorrow.

Thanks guys

I’ve been using csv + store up till now but it’s seriously clunky for more than the simplest cases

I really should look more closely at message. Looks very useful

I’ve actually started using the sqlite nodes and this seems to be a good solution for my needs. Am currently making some helper modules to let me store various attributes (filepaths, values etc) and associated gui helpers (file browsers and the like)

I’ll try to report back

found an app called SQLite Databse Browser which is useful for planning and building the intial database

Attached is the result of today’s tests in case anyone is interested

sqlite seems to be working well so far…

I used this to build the database http://sourceforge.net/projects/sqlitebrowser/

gui sqlite tests.zip (32.9 kB)

Well, for me I write JSON files because it’s easier to make, read and use than XML. All advices above are good too, depends on cases.

use c# classes, if you create a dictionary or a list of objects and you propagate them as a spread or even better the collection itself, the sink nodes will write and read the object instance created in the source node, which means if you send that object out with s/r nodes you can edit a single object instance throughout the whole vvvv project. i will show you a general purpose implementation of this tomorrow

wicked, thanks md. Have never been that sure about sink/source

@clone - how are you building / parsing your json?

To build and parse I use “element” node and friends. It’s not the most handy way I admit, you have to make node cascade… but it’s working.

Anyway, if it’s only GUI parameters you have to save, why not just building a simple text file and use specific separators ?

JSON or XML are good with loads of data but in case of GUI preset I guess it’s not that big.

formatted text works well for single sets of data but gets a bit clunky managing things like multiple pages, and different data types.

SQLite is working really well. That browser utility is great and lets me build the structure for each page with a nice gui. I’m building a table for each gui page or set of paramters.

@mrboni: if you’re still curious check this out: https://github.com/microdee/VVVV.Packs.mcro/tree/master/nodes/Plugins/RawObject