On Wed, Sep 30, 2009 at 9:06 PM, Christopher Wright <[email protected]>wrote:
> 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. > Well, it doesn't seem that the patch is meant to store values in the input port, given the way that you interact with it and what the user does to make input ports appear. For instance, if I publish an output from a splitter, and the output from an interpolate connected to a sprite, I get two input ports on the feedback patch; one called Initial_Result, and another called Initial_Output. Note that there isn't a way to automatically add initial inputs on the feedback patch itself (or initial outputs, depending on what the heck we are going to call them). If this was possible, and this behavior occurred, I would agree 100%. As is, if there is no cable connection, then there is no monitoring of that published macro's output, and it could be expected that the input should be 0 (at least by me). The feedback patch creates keys that are correlated with the published key you've made for output on that macro level, and appends "Initial" to it. This seems to infer that conceptually, there is supposed to be an actual connection made if one wants it to evaluate that initial output (or whatever the name is, depending on the output key published). The published macro outputs, and the inputs of the Feedback patch, are supposed to "match up" given this interaction method to make input ports of the feedback patch appear. It's definitely no longer being used for the purpose of monitoring the published output if there is no connection going on anymore via cable/noodles. Why not a 0, in this case? There's not a corresponding connection anymore, so no value is being delivered. > 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! > Sure, I can contrive many additional scenarios where problems could occur from this. I agree totally. > > > 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. Since one can't make the port appear on the feedback patch to begin with, sans published output on a splitter or other patch, it seems to be more than just a workaround but contingent to the concept of the patch. The actual definition of the patch is that it gives access to current values of published output ports of a macro patch, not that it delivers output values itself. If there is no connection, then it's not really being used to observe the output value of the macro anymore, it's being used for another purpose (not saying it isn't a valid usage scenario though). Maybe this could have been clear by making noodles automatically connect or have info sent sans spaghetti connection, but that would have been ugly. The alternative line of thought to this would be, if you have to publish the output to have the patch refigure and make an additional input port appear in the first place, why *not* connect it, or leave it connected? To be sure, I'm not saying there isn't a solid case for having approached a patch like this differently and just having allowed people to make as many inputs as they wanted, and not have it be tied to publishing outputs first. For a winning method of interaction, one should just be able to add additional input ports via settings, and have it maintain port value in the way Steve wants. It's evident that wasn't the concept, and can see a valid case for why it works like it does given the user interaction needed to make inputs appear. I would have never setup this kind of interaction approach to make a patch work in a million years given how unclear it is for people to use it successfully, so I don't want to go too far in stretching logic to justify the interaction needed to make this one work as would be naturally expected by anyone just feeling the patch out. -George Toledo
_______________________________________________ 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]
