This does appear to be a bug. The feedback patch will output the value
that the output had at frame n-1. If the output is dependent on the
input, there needs to be a way to define that value at n.
Troy Koelling
On Sep 30, 2009, at 8:10 PM, George Toledo <[email protected]> wrote:
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/tkoelling%40apple.com
This email sent to [email protected]
_______________________________________________
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]
