FrameDelay Init

while cleaning up the generic version of framedelay for the addonpack i stumbled upon an - at least to me - unexpected behaviour of the native node:

banging the init pin writes the default value to the output, but with one frame delay.
i always thought the ((pin:Initialize) would behave like a reset to inject a new value instantly. at least it’s often used that way when patching increments and counters and alikes.

so, is this behaviour intended and why, or did it just slip through?

FrameDelayInit.v4p (5.6 kB)

this might be necessary to kind of “unstick” different parts of a patch in terms of graph evaluation. when you have a framedelay between two sections of a patch, it suddenly does not matter much, which part gets evaluated first, if it is the upper or the lower part.

an init pin that reacts in the way you propose reintroduces importance of evaluation order again

hey woei,

we are on it! and thanks for noting! we also needed to adapt the plugininterface a bit for that and had a retry on writing our generic framedelay.
just wanted to give you a shout out so that you don’t put work into it at the same time. will com back on it to clarify some details

hey velcrome et al.,

thanks for the thought on that issue!
let’s just test some design possibilities together.

let’s state the core functionality maybe like this: framedelay stores a value for the next frame in a way that it can be seen as a barrier beween frames. it breaks up evaluation in a way that allows feedback loops. focussing on a single frame the output is independant of the input. evaluation stops here. independantly from that the input is evaluated to store a value for the next frame. so the output pin serves as the data source, and the input serves as a sink.

we could visualize those two functionalities in our heads like that: a “setter” that replaces the input pin and a “getter” that replaces the output pin. while we loose the visual representation of what happens between frames, we get a better feel for what happens within one single frame: the getter would be at the top of the patch, the setter at the bottom.

now i only see two ways how we could define the way default and initialize pins should work:

a) like a switch just underneath the getter.
b) like a switch just before the setter.

what we have up to now is b). when starting a connection from the output pin, it makes sense that all input pins lighten up: since the switch is down there in the patch just before the setter, we can connect the source with any of those pins. so that is at least consistent. i also checked again the way it is implemented and indeed everything matches the idea, of a switch that comes into play while storing the value for the next frame.

anyway i think woei is right and this is not what we want. we want the framedelay to instantly output the default value when init is true.

  • init should match the behaviour in the first frame.
  • we have no “constructors”, so when we want to do some initialization we need a way to do this asap (not in the next frame). the patcher gets an early “entry point” and a defined behaviour for the first frame…
  • delaying things that don’t need to be delayed just feels wrong
  • the standard design pattern of using a framedelay feels ok with that implementation.

the consequence of this implementation (a) of course is that you can’t connect the output to the default or init inputs. and i guess that is what you meant?
i think this downside is not too hard, since as a patcher you always have the possibility to use a manual switch anywhere you like. so this whole topic is really more about a good default.

if there no strong counter examples than we’ll go and make old framedelay legacy and reintroduce implementation a) with next beta.

framedelay usage pattern.v4p (5.1 kB)

while it seems more consistent in terms of visual programming to have all inputs pins evaluated in the same frame, the node itself acting as framedelay and the outpin always passing on the value of the last frame, from the usage perspective it feels more appropriate having the Initialize and Default as immediate override - switch before the setter.

what’s the opinion of the rest of the crowd though?

edit: to clarify: switch before the setter meaning the initialize affecting the output immediately in the same frame

can’t we simply have two init-Pins for both scenarios?