evalOPs cooking question

General TouchDesigner Discussion
, ,
1

Hi there,

So I need to start a process (i.e. update a replicator) whenever the value of a par.evalOPs() call changes. I tried to create a tox that speaks for itself. How to I trigger the cooking elegantly?

thanks,
Josef

evalOPs_cooking_question.tox (774 Bytes)

2

So I assume you’re not trying to see if the parameter expression changes , as you are using a wildcard in your example.
So it seems (correct me if I’m wrong) you’re trying to see how many nodes (null1, null2, etc) fall under that wildcard expression.
Perhaps a solution could be to use an Opfind DAT, and perhaps tag the nodes you are looking for. The Opfind DAT will cook automatically on any event that would change its searchresults.

3

This is interesting because the expected behavior is for the evalOPs() expression to be fully dependent on the network and update itself, which does happen when removing nodes but not when adding (try adding a few new nodes and then remove one of the ‘mapped’ ones) . Perhaps this is a bug or unfinished behavior?

1 Like
4

I can replicate your problem. Will get that in the bug queue.

@nettoyeur’s workaround is good.
I also tried using a parameter DAT with the wildcard set to one specific par on the watched operators. In these situations you can watch the DATs for any change in size using a datexecDAT and recalculate the evalOPs at that moment.

My testfile with workaround is attached
evalOPsBug.4.toe (5.7 KB)

2 Likes
5

Yes, I fully agree!

6

Thanks Ivan,

Unfortunately, I don’t see how this would work if I have a custom parameter and the functionality on another network level.

evalOPsBug.toe (5.6 KB)

7

@josefpelz

If you want to post your actual network that you’re trying to get to work, I can show you. Or if it’s private you can send to ivan@deriative.ca

8

Thanks! I think with the last example I send it should be clear what the issue is I’m running into. If you’re able to fix it there, I’m happy to see that solution(:

9

Like this?
evalOPsBug.7.toe (5.6 KB)

10

Great!
That does the trick.

11

There’s a simpler workaround, which is to make the Operators parameter an expression:
ops('circle*')
instead of the constant
circle*

The reason this works is that the value of the parameter is now changing, so it’ll notify anything monitoring that parameter. The actual list of nodes is built in the cook method of the Parameter DAT so it doesn’t notify nodes that are monitoring the parameter only. Hope that makes sense.

3 Likes
12

Thanks, that works indeed, but I want my COMP to be as easy to use for everyone. That would be very unintuitive for others.