I realized a framedelay when using a pad instead of a direct link connected to an input pin. Is it automatically adding a framedelay when writing to/reading from a pad/properties?
And if so:
would this mean to better avoid using pads/properties when not necessary?
is using a framedelay-node or a pad/properties more recommended if it’s just about enabling recursive patching?
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.
For example:
Prepare
Calculate/Process
Draw
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.)
also for reference, if you just want to get rid of long links and want to stay in the same moment when an operation is called, i.e. have no frame delay:
