On Thu, Oct 1, 2009 at 12:54 AM, Christopher Wright <[email protected]>wrote:
> 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 :) > Come on. Please! Totally not necessary. > > 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 ;) Since the patch is externally driven by other events, it's a novel new patch, and input ports are configured in a way that is contingent upon value being based on the previous frame of the corresponding published output of the macro, I never thought of *not* connecting something to one of the inputs in a scenario like this, if I wanted the initial value to reflect something other than the macro's output value. The output value of a macro like the one in your example is "", so it would seem that it would be functional for the input port on the feedback patch to not restore with a value, even if it does wind up in the plist as a side effect. Inputs store values, but outputs don't, and this input is predicated on an output by default. 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. 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. > > > 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). We're on the same page; somehow I must have conveyed that I was seeking clarification or thought this was odd. > > 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. We mean the same thing here again. I'm saying that making ports isn't contingent on any settings on the patch itself, but on publishing something out of the macro. > > > 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: > > > > > 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. > 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. > 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)? 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. > 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. > The output text of the top string is blank, and the output of the macro is "" before the composition runs. So, this is expected to me, since it *is* the value of the output. In the bottom case, that's not true, and there is something that would logically override (at least in my concept of things). > 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. 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. > 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): > > (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. > > Yep, I've used this same kind of setup to pretty well received effect ... this is all understood. > 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). > 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. > > 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). > I really didn't feel like anything about it was that steep (you'd probably laugh if you knew the full irony of the fact that this discussion involves this kind of scroller setup... I've never had a more successful setup than one very similar to the Leopard feedback loop you posted). With this particular situation and patch, I thought that it made sense for the values to get "snagged" from the output port in a scenario like the top one (in your attached SL problem case qtz) so that it reflects what the output port actually is upon opening the qtz instead of what it was the last time the qtz was used, and that it probably had to work that way for it to be functional in every possible scenario. 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. 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). -George Toledo
scrollers are mega awesome.qtz
Description: Binary data
_______________________________________________ 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]
