I'm under the impression that since the feedback patch is a kind of external provider, that it needs to be actively sent the input values (whether or not they are stored in the plist as a side effect). If you have your splitter actually connected to the initial output port, and the splitter's input value is 42, only then will the 42 be sent to the initial output port, and then the "actual output".
If that's the case, why even have initial input value ports? Those ports exist so that you have something to start from before the first frame has completely rendered.
Let's say, for example, that you wanted to sum an infinite series using QC (don't ask me why you'd want to do that :) -- 1/(x^2), for example (which sums to 2.0 if you do it infinitely, or 1.99999.... for numerical approximations).
so, each frame, you want to take your previous value, sum it, and divide it in half for the next loop (published output).
If you have your initial set to 1, you'll use 1/1 (initial divided in half). That's correct for the series. Subsequent frames would add 1/2, 1/4, 1/8, 1/16, you get the idea.
After infinity frames (disable VBL sync!), you'll accumulate to 2.0, and your math teacher will love you.
But with this bug, the initial will be 0, even once you set it to 1. So you'll start off with 0... then 0/2... then 0/4, then 0/8... this summing isn't getting very exciting. And, more relevant, it's also wrong. With this bug (ignoring the splitter workaround), it's impossible to sum this infinite series!
While the situation above is unrealistic and a bit comical, hopefully you see the point: feedback without controllable initial conditions is much more limited than feedback with initial conditions. A splitter works around this, so it's not a show-stopper, but an annoyance none the less.
Maybe the thought is that re-opening and having these values not clear (if not connected to something delivering the value) would be akin to having a qtz that is mouse driven restore with the mouse coordinates that were happening when I closed the composition, so it was designed to clear by default since it's not being driven by any event. When the qtz is opened, this all gets evaluated from the "new" moment. I think this is a part of why it functions like this, though I guess anything is possible.
The input ports are never set while the composition is running -- they're _Initial_ values. The feedback patch uses them in exactly 2 instances: when t=0 (first frame), and when the UseInitialValues input is set to true (I forget the name, forgive me). When those conditions aren't met (most of the time, unless you're using the UseInitialValues port), the outputs are set from the containing macro, and the inputs are ignored (not set to the current state). so accidental corruption by saving while mousing, for example, isn't possible.
-- [ christopher wright ] [email protected] http://kineme.net/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Quartzcomposer-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartzcomposer-dev/archive%40mail-archive.com This email sent to [email protected]
