i want the feedback loop to stop (set S+H to 0) when first slice of returned spread is 0. manually (bang for each iteration) it works. well… i stop banging then.
automatically (if slice != 0 bang) it doesn’t, it seems to just skip over the 0 and doesn’t stop…
with a few different spread inputs, which also become 0 after some iterations it does work automatically though… so in principle this should work… i don’t get it… :(
patch is pretty complex, i can’t simplify it or reproduce the problem, but if patch is needed, i will provide it.
i see that the condition to stop sampling is situated above the s+h node. depending on where you insert your slices, this could mean that the s+h node only stops sampling one frame after a 0 is found, then continues as a different slice is inserted …
i recon the stopping condition should be dependent on the output of the s+h, not on it’s input. the input can still change, but the output won’t once sampling is set to off.
*Do not use S and R nodes as an {TAG(tag=>strike)}lazy{TAG} easy approach for keeping a clean structure in your patch.
+
+if the dataflow is not clear enough: visible links are better to keep track
+if your patch is looking messy: better move your nodes around till dataflow looks somehow logical.
for some reasons you may need S and R nodes:
*all nodes in common have a configuration pin: Descriptive Name
+very useful for commenting, especially regarding the S and R nodes.
+
+for exactly this reason i once patched the SetDescNames (VVVV S R).v4p-module.
+you find it here: kalle.Modules.VVVV
you are fiddling around with several a,b,c,A,B… comments here.
*Toggle B sends a boolean, not a bang!
+
+use the UpEdge output of TogEdge (Animation) to get a bang.
+take care: the DownEdge output of TogEdge (Animation) bangs on patch startup; no matter whether “Bang on Create” (hidden by default…) is set or not. (IMHO a bug)
patch related:
*you DO delay both Input and Set of S+H (Animation) .
+
+maybe moving the Input’s FrameDelay behind the S+H AND bypassing the Set’s FrameDelay already solves your problem.
*hhhm. or move the Input’s FrameDelay between InsertSlice and CAR.
more Annotations
really not easy without the patch.
i know very well that those FrameDelayFeedbackIteration-things can be really mindFAQing.
*in general attaching a (please: reduced…) patch is always better than a screenshot.
but in this FrameDelay-Feedback context for your own practice i consider as a good brain exercise:
*looking at the patch like it was a screenshot
*and trying to think framebased
**what happens in the current frame?
**which node processes data from current frame as well as from previous frame?
only one thing is sure here:
your switch is one frame late.
