I understand what you are saying about persistence of data, and the value being lost, etc., the process the plist goes through as each step of this all happens, etc., and had observed this. I'm also not inferring a queue functionality with the one description, but a scenario more like an accumulator setup. I thought of the feedback patch as being something akin to having a sample and hold, or accumulator, where you need to feed it with a value in a certain way if you want the evaluation to kick off successfully in to begin with, but a bit of a special case patch given that I was perceiving it to be a little bit outside of the typical QC evaluation model as well. The initial value is held in the plist, so that is a tell as you say.
My concept of signal flow, totally apart from QC, has me think of the value/event that starts a feedback loop as being separate from the loop itself, so when I encountered this and had to explicitly hook something up, or publish the input, I felt it was a matter of something having to "start" the loop successfully apart from just the using the input port of the feedback patch itself since the function of the input port was to automatically try to configure itself if it isn't connected, whenever you start up the qtz the first time. I was viewing the whole macro that gets created as a successful feedback unit unto itself and the feedback patch/utility as only part of making a successful feedback loop, and that the entire macro had to have a "start" point that was apart from the feedback patch itself. Furthermore, when it worked, I was going, "ok, this *is* how whoever designed it was thinking about it as well". The fact that I couldn't put consumers in macro like this made me feel that it fit a kind of protocol scenario/rule, and that I needed to build a "feedback unit/macro" of sorts in order for things to work correctly. In most of those kind of setups, you're building a macro that is predicated on published inputs and outputs, or you ignore the published input and jumpstart it with something (like connecting something inside of a render in image patch to an image protocol output, to make things start evaluating as a sort of pseudo image unit). This seemed to fit squarely into the scenario of having to either use the splitter in this scenario, or publish the input and build a kind of feedback system macro. (Yes I grant you caveats about other patches restoring with the state... again, I thought this was more of a purposeful byproduct of full integration of this concept). To digress from QC for a moment - with feedback, I have a value that I generate and feed into an input of a device that is capable of creating a feedback loop. Input A does not inherently store this value in a typical signal chain, it's predicated on it being delivered to it from outside the device that causes the feedback loop. The initial value of a feedback loop comes from outside the input of the device that creates the loop, and then subsequent feedback is predicated on the output (in a scenario like these string examples, or when creating visual or audio feedback on other systems, analog or digital) snaking back to the input. The input of the feedback system is now drawing from the output, after being kicked off by the initial signal, which came from *something besides* the actual piece of equipment/unit that MAKES the feedback. So, regardless of normalcy in the world of QC, it seemed to represent how I thought of a feedback system as typically working. Meanwhile, stuff not dependent on the feedback... value adjustments on compressors, gates, eq, etc., is exactly in state, because that "how I left it" and not dependent on the values that set off the feedback loop (that were external from this device that makes the feedback circuit). I'm sorry to digress into analog world, but that's what the computer system is emulating at the root of it all, no? So, to me, something that generates feedback would need to deliver nothing, by definition, if something wasn't hooked to an input port, and it's a valid case for an exception to the QC norm. I had just thought it was the solution for this working itself successfully into the QC paradigm, and however things need to be ordered to evaluate correctly. It's reasonable for whatever the "kick-off" value is to be stored in the patch, as well as anything like the current setup's implementation. I totally see what you mean about this being weird as far as an input port not restoring, but it didn't seem weird in the context of feedback, *to me. "Oh nothing is plugged in the port to kick it off, no wonder it is no longer going to be feeding back like this". *I had been thinking that this was clever and even intentional! ;) I've probably inevitably phrased something unclearly here, so I want to make it very clear that I 100% believe in your analysis of this, and the conclusions you've come to. * * I defer to everything you are saying in the context of whatever is typical in the realm of QC patch programming and function, the evaluation model, restoring state, etc., and whether or not this is broken. The fact that it is something that isn't expected by multiple people, and that causes this much discussion about something so trivial, is certainly cause for concern and a bug report. -George Toledo On Thu, Oct 1, 2009 at 8:10 AM, Christopher Wright <[email protected]>wrote: > 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 -> outputPorts > > No 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/ > >
_______________________________________________ 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]
