I’ve talked about FrameDelay vs. Pads in this video. Please watch, starting at 04:45:
Yes, pads always introduce a framedelay.
Well, i’d put it this way: Only use them for what they are intended, i.e. storing data in a datatype. If you’re looking for a way to get rid of visual links in a patch, that’s not what they are for.
While for those scenarios, as a user coming from vvvv beta, you’d be used to use a FrameDelay because you didn’t have a better option, a VL user here can start thinking about storing data into a pad and reading from it. this puts much better emphasis on those crucial parts of patch.
I’d argue this confusion only exists for vvvv beta users, that’s why it is mentioned here. Mentioning the idea of a framedelay anywhere near properties wouldn’t help a VL user but only would possibly add the same confusion.
For rather large process nodes I use pads internally across different operations of the process.
Prepare has the inputs, maybe does some validation/pre-calculation of the parameters, then store’s them in pads for the second process operation, which stores its results in pads for the Drawing part.
Pads introduce framedelay, but only inside the same operation. Not if the second operation is called after the first.
To enable operations beyond Create/Update in a process node, you have to enable those in the menu to the left to have the process include those (and make sure the order is correct, have 1 run before 2, 2 run before 3.)