I was thinking "ok, I guess I just need to "drive it" with something for it to evaluate. I ran into this exact same scenario, noted it, found the same workaround, and didn't really think about it any more (but I see the point here, don't get me wrong) since it worked ok.
There's no precedent for needing to drive input ports so that they preserve their values. When the visualizer isn't open, no data flows, period. In that case, there's no reason to trash the input port values (where did the pulling happen, since it's not rendering at all?).
This scroller example sheds a bit of light on the "why's" of exactly how this led to such a head scratcher ( I wouldn't have thought to setup a scroller like this in a way that isn't 10.5 compatible since it's already possible with current patches).Troy has said this appears to be a bug to him, so perhaps this is all moot and academic. However, I'm still interested in the concept of an input port that is supposed to be n-1, predicated on the output, and simultaneously, not clear the port without being explicitly hooked to something. How could be it rely on an output value and not clear upon opening if the output value of the macro is technically "". It seems like those are opposing definitions.
The definition's a bit more involved than that. It relies on the output under normal circumstances, but under special ones (i.e. initial frame, or when the Use Initial value is true), it uses the Initial_blah values. Regardless of that definition, there's no precedent for /Setting/ the input ports from within the patch to the current state. The only patch that does this that I'm aware of are the GLTools Grid patches (which do that so you can update the grid in- memory without needing to explicitly set every aspect... it's a hack, but it works). Within Apple-approved-land, nothing sets its own input port, ever, and this is (shouldn't be?) an exception.
What is the initial value of the macro output minus 1, when you open it? Is it the same as what the actual value in the input port would be when it was closed? This is why I find it normal to 0 out unless hooked to something to over-ride what I interpret as the default function. I absolutely do find it interesting that the value is stored in the plist though.
Initial value-1 is undefined. Initial value /should/ be defined by the initial_blah ports. The initial value should be whatever you set it to (the path will not update its inputs, because that's icky), for reuse when the composition is started/restarted (or the containing macro, if you enable/disable it with a local timebase).
Again, because of the basic logic of what I thought that input port was supposed to be doing; monitoring the output and contingent upon whatever it is, but at a frame before. It does store the value while running, so I felt like it fit the bill.
The storage is internal to the patch -- the port is simply 1 way to potentially change the port.
The values are stored in an internal array detached from inputs and outputs, or the values are stored in the output themselves. checking under the hood, it looks like the former (a QCArray of values). The patch in non-initial/reset conditions will populate that arrays values from the containing macro's outputs, leaving the inputs untouched. It then populates the outputs from the values in that array. It's a bit unusual, perhaps, that things are stored in triplicate (initial port list, internal value list, output port list), but that allows for flexibility.
so the basic data flow is something like this: initial/reset condition: Input Ports -> array -> outputPorts other condition: macro's outputs -> array -> outputPortsNo input ports are modified, except by the user (which is "right" according to QC's history).
Well, if it pulls the value, again, it should open with a "" unless something is setup to make that not happen, since that's the output value of the macro.
"something" = "initial condition input port" :) (though it doesn't work, which creates this confusion ;)
The inputs would get their values from the cables that are connected to them, and but pass a value from the previous frame on the output port. It would work in the way I described.
So that's a queue then, with a queue size of 2? I'm not sure that's too useful (I mean, it solves a common problem, but that was already solvable previously. The feedback patch itself may fit into that category as well, but it definitely makes things more convenient) (Another feature: a multi-input/output queue. and a multi-input/ output smooth. for brevity.)
Thanks for the discourse, and believe me, I definitely see your points. I have a feeling that maybe you may be under a mistaken impression about my having/having not dealt with this kind of loop scenario, or in having looked at the feedback patch, and my understanding of it.
No problem :) I'm positive you've worked with feedback pre-Snow Leopard (I've seen it :), it's just the initial-condition boundary case that I'm not sure we agree on. You understand it, it's just that in the face of this bug, smokris/troy/myself have gone and declared it a bug, while instead you simply looked at it, and said that it could make sense. Rightness/wrongness is, as always, left as an exercise to the reader :) There's plenty on both sides to have it work either way, I just find the current implementation to not follow the QC standard (namely, throwing away data the user expects to have preserved at the input ports).
In any event, you don't need a splitter to workaround, this is how you set it if you want it to do what you two are looking for; publish the input value. Check out the attachment. Again, this makes sense to me, as the input is no longer on the macro level that would make it "clear" (in my concept of this).
It works, but not out of design -- publishing a port is similar to attaching a splitter (it then takes a value from another port, which properly unserializes its value). That that make it work "intuitively" is purely coincidental.
-- [ 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]
