Quaint, that the Feedback patch is causing a circular discussion :)
This may sound argumentative: it's not intended to be that way, so please read it with a happier tone (I've been coding a bunch today, so my talk-to-humans filters are disabled) -- we're still friends, don't worry :)
On Sep 30, 2009, at 11:10 PM, George Toledo 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.
I don't follow -- what about the interaction model of this patch (completely independent of the blue noodle interaction stuff) makes it ok to discard input port values (yet still mysteriously store them in the plist) when no other patches/ports do that (except for bugs in GLTools' spline patch ;)
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.
This is completely intuitive: For each published output of the containing macro, an input and output are created on the feedback patch. 2 published outputs = 2 inputs/outputs. The outputs are the values from the previous frame, so Macro output A's value goes to the feedback's Output_A output the next frame. The first time around, there is no Output A value, because the macro hasn't evaluated yet. That's where the initial value (should) come into play -- it gives you a starting point that isn't necessarily zero (or technically undefined, though that doesn't make sense in QC noodles).
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).
There is a way to automatically add input/output pairs: publish an output in the containing macro. It's not magic :) Note how _every single_ example composition that uses the feedback patch has it in a macro with published outputs. There's an exact 1:1 correlation between containing-macro published outputs, and feedback patch input/ output pairs.
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.
It's impossible to evaluate the initial output -- the initial output could in fact depend on an initial input (which is what this is all about). It's not always the case where an initial condition is needed, but there are cases where it is.
Here's an example of what I mean:
scrollers.qtz
Description: application/quartzcomposer
These are 2 simple steady-state text scrollers. Each frame, they take their current output (via the feedback patch), and generate a new output string that consists of the last character of the string, combined with the string minus its last character, producing a cheap text scroller marquee effect.
However, when you load it up, you'll only see 1 marquee. that's because we've got a splitter to the initial input (the "workaround"). In the top scroller, it is /Impossible/ to have it generate anything, even though it should (there's an initial value, just like the other macro. There's no hidden logic, no smoke, no mirrors, no handwaving). The initial input is intended to address this sort of case, however, because it doesn't restore the value from the plist properly, it fails to do so.
Sure, I can contrive many additional scenarios where problems could occur from this. I agree totally.
So if you agree, how can this be _anything_ but a bug? how can there possibly be a use case for an input patch that never stores any meaningful value on its own, unlike countless other input ports dating all the way back to 2006 (or earlier)?
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.
You're mistaken: it cannot give current values because those values do not exist -- in the scroller above, the output value _depends_ on the input value exclusively. In such cases, an initial value is needed.
Think of like conway's game of life: the initial value is whatever the starting frame is. it "works" when there's no starting frame, but it's really boring (all blank). The feedback is _exactly_ the same way: it allows you to take the current state (previous frame, fully computed), and do something this frame based on it. Check out the video feedback example. now attach a sunbeams patch to the initial image output, and restart the composition. Notice how the sunbeam image swirls off into the distance? That's that initial condition kicking in. It works here because there's a patch supplying that output, just as splitters can provide strings, numbers, etc. However, this supply is not and should not be necessary: initial state should work perfectly fine on its own, no strings, er... noodles attached.
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 connection's also unnecessary: the feedback patch automatically pulls the port values from the macro each frame anyway. Initial_blah isn't necessary for this type of functionality.
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.
You're mistaking current frame for pervious frame. Here's _exactly_ how the feedback patch works (assuming the bug didn't exist -- the initial state is the first input on the multiplexer):
LeopardFeedback.qtz
Description: application/quartzcomposer
(works on leopard)see how it accomplishes the same thing? That's all there is to it. The Feedback patch is doing just that, only much more elegantly, and with some transparency (pulling the values for you). And the feedback patch doesn't need the loop in the graph, which makes noodling much easier to follow.
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.
Where would those input/output pairs get their values from, then? if you an add arbitrary input/output pairs, it's nothing more than a glorified multi-port splitter (note to Troy: this would be a handy patch, and all your users would send you exciting presents if you made a multi-port splitter for compactness ;) since it won't update automatically (from the containing macro outputs).
Regarding the setup: it's actually pretty simple, it's just the initial state quirk that makes it weird. it's already possible with leopard-only patches, and I've done compositions that actually do similar things. This tidies it up quite a lot. The learning curve may be a bit steep, but it's nothing that really needs logic stretching or justification -- there are decades of research on feedback-type things (IIR/FIR filters are a trivial example).
Anyway, rdar://7267165 (smokris, I stole your procedure when writing it up -- hope you don't mind)
-- [ 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]
