Question #1: what is the difference between DAT Execute dats and a textbox with the on DAT change checked?
Question #2: 90% of the times, my widgets act on input changes and make things happen.
This usually means that I need to have a script that reacts to changes (on_change) then a script that cooks on created (since if the contents change on create the on change dat doesn’t run), which calls on_change. Then a script that runs on start since also then the on_change wouldn’t run (there are several cases where I needed that I can’t remember). So a lot of times I have to create 3 dats when if the oncreate and onstart flags where added to a text top with all the various flags (ie. on dat change), I would only need one dat. It just seems overkill - lots more dats - and I’d like to know why that was the choice.
regarding #2, I’m with you. I also have mostly 3-5 different DATs (start/create/panel, but sometimes also a DAT/CHOP monitor), just for admin tasks. So I’d also like to see an option for the text DAT to simultaneously turn on all the execute options and then use arguments and if() statements to trigger the appropriate behavior for each trigger type.
For #1, achim is right, there is no difference, but any future features will be put into the DAT Execute DAT, not the Text DAT.
Our plan was to actually phase out a lot of those features in the Text DAT (anything that’s duplicated in another DAT), because we felt it was getting overloaded (dont worry, we’d convert over things automatically), and was making networks hard to understand. Networks are just becoming a mess of Text DATs. Atleast with the DAT Exec, CHOP Exec etc, you can look at a network and get an idea of whats going on.
What if we added an $arg that let you know what kind of trigger made the DAT go off. That way you can contain your scripts in single Text DAT, and then wire it to each of the *Execute DATs that you need?
But we would still end up with many DATs, wouldn’t we?
1 for the script
1 for on start
1 for on create
1 for panel changes
1 for dat changes
…
not that one always needs all these, but I usually need at least three just for admin tasks. Maybe it’s just me and my setup, but as my component tends to get used 500+ times in a file, I wanna reduce opcount as much as possible. Same for any UI component that get created via a script. Every node saved should make it create faster …
I agree with Achim, and as far as not being able to understand what’s going on in networks I think the issue is one of naming conventions and grouping/components.
I though the reason why you were moving away from the execute dat was one of speed. If it’s not, I think the execute dat is great and it should have all the create/start options that you’ve added to the text dat, plus a parameter to let it know why it’s being called.
speaking of being perfect. There are so many different triggers (opecxecute, parmexecute, chopexecute, datexecute, on start, on create) that they obviously can’t be put in a single node. But we often need a certain/different combinations of all these and don’t wanna create 5 extra nodes.
So here’s an idea. A simple script DAT with let’s say 10-20 integer parameters.
In each one we can put one of a bunch of new expressions, which will:
a: pulse to 1 if true and therefore trigger the script
b: supply additional arguments to the script depending on the expression
The expressions would be the individual options of the various *execute DATs: From datexec
onDatChange(“path”) From parmexec
onValueChange(“parameter”), onExpressionChange(“parameter”), … From opexec
onDeleted(“path”), onFlagChange(“path”), … From text DAT
onStart(“path”), onCreate(“path”)
The following two are bit difficult as they have “offtoon, …” modes
onChopChange(“path”,"channel1 channel2 channel3,“offtoon”)
onPanelChange(“path”,“panelvar1 panelvar2 panelvar3”,“ontooff”) so the expression’s return value can “stay” at 1 if the additional argument is whileoff or whileon
All would be executed from the script’s path, alternatively each of the 10-20 trigger parameters could have a path parameter next to it. The nice thing is that it would basically also allow to use any other touch expression to trigger a script (but no arguments will be supplied except the parameter ID which triggered the script)