Let’s assume I have an Execute DAT node “A” with some python in it using the me.store(“key”,“value”) function to store some data when the monitored table changes.
There are a couple of things I’m not quite clear about.
how does such node sets via python its “output” value, the one made available to downstream nodes connected to it, potentially triggering a cascade of updates?
how can another node (connected to A or not) monitor the storage in node A and trigger a script within it, whenever that particular key changes value?
The Execute DAT’s content is the text of the callbacks - that is also what is transported via it’s output to the next operator. Storage of data via the me.store() is specific to an operator and is not transported down the branch to subsequent connected operators.
You can make use of Dependency Objects and the available callback method to react to changes.
Generally speaking, often times data would be stored in extensions or expressed in a way that it can be viewed as one of the OP Family data types.
Ha! This simple fact didn’t quite occur to me. Now you said it and of course it’s obvious. =D
Yes, this is quite clear. I was hoping there was a way to monitor the storage for changes, but it seems that the operator owning the storage must somehow trigger the changes downstream instead, with a pulse perhaps. But pulses are parameter-specific if I understand correctly. In this case there is no parameter involved. The value stored could be anything and not necessarily something that can be natively stored in a parameter. I guess I could use a dummy parameter, whose content is irrelevant, to trigger a pulse?
I’m trying to understand how to move arbitrary data through operators that are visibly connected to each other. I.e. a dictionary or a list of lists of lists. I can see how tabular data and text flow through, but ideally I’d pass arbitrary python objects, process them along the way until, say, the data ends up in an operator that visualizes it.
I guess what I’m looking for is a generic way to pass data from one python script to another, each script in its own operator and the script operators visibly connected to each other. The latter requirement, visible connections, is not strictly necessary, but assuming the scripts form a pipeline of some kind they all should execute one after another automatically.
when dealing strictly with python data - meaning data that can’t be expressed via other operators - we tend to use Extensions and deal with it there. Can’t particularly see a good reason to try to push this into operators as the data itself would mostly be hidden in storage anyways (but I can be totally wrong and in your particular case it would make sense)
Now having said that, you should be able to work with Script DATs as these will cook if the input cooked, triggering the onCook callback in which you could fetch the stored object of the input operator.
Aaaaaahhh! This is perfect!! Concise and flexible. Thank you Markus.
Extensions: I did go through the documentation pages about them. Right now as a newbie I find them quite daunting. Perhaps because I don’t have a use case that is complex enough to warrant them? I can see they start to make sense when one wants to encapsulate somewhat complex behavior and create an easy set of parameters and UI to go with it to control it. But perhaps I’m overcomplicating things?
