> Re: Do I misunderstand the iterator or is this a bug? > > So lets make sure im right on this right - when an object is inside an > iterator there is only one instance of it. The iterator then just > reuses this object each iteration causing the resulting behavior. > > The reason I tried the smooth patch was because I'm writing my own > plugin that averages data over a period of time and was having the same > issue with it. How can I enable this plugin to know its inside an > iterator and to not spaz out.
I think you are misunderstanding the iterator AND smoothing. Think of the iterator as a macro to create instances of whatever object. If you are used to objects in code, then the properties that you are changing -- the variables going into your instance are your "methods." Every instance is a new object that inherits the properties of the original. But it doesn't keep a record of the individual variables, unless you store that outside the object. Internal variables, are going to be true for ALL of the instances. If X = 0, and Y = 0 without some other changing property like time adding to X, each and every iterator instance will be sitting at 0,0. There is no difference between iterator 1 and 10, other than some factor that you changed -- usually this is time or the number of the iterator itself. But it has no history other than the entire iterator instance as a whole. You should depend upon arrays outside the iterator, and the iterator variables inside the patch to know which object in the array you are addressing. If you wanted to use any SMOOTH function, you would do that to the data stored for a single instance. Or probably, just create a complete macro for each item you were smoothing. I suspect that you are going to have to use the Javascript patch, and just code in your own smoothing. Use a multidimensional array, and record all your values over time -- and then find the standard deviation to get the next value. You would probably need to initialize this with dummy data at first. It could probably get pretty unwieldy quickly if you tried to "smooth" too many array values -- I don't know if the new Javascript optimizations that will be helping Safari and the iPhone are going to help Quartz. My next "guess" as to what you could do is to use a smoothing patch for each iterator instance outside the iterator. Use the first iterator as an array itself, and a 2nd iterator for display. The first iterator would not have a consumer patch in it for this trick to work. But, say you had ten items you wanted to smooth. Iterator would be plugged into a multiplexer with ten outputs, and it would export the iterator variable for the index of which instance and variables it was effecting -- say something like X and Y position over time. The multiplexer would output to ten separate smooth patches -- thus keeping a record of the data and better efficiency than a Javascript patch for determining a standard deviation (if I'm looking at what a smoother really does). The smooth patches could then go into some other patch that would allow the data to fill a structure. The second iterators only job now is to take this structured data, and apply the calculations based upon iterator variable to match the index up with the "smoothed" data, and then display this on the screen. I hope that makes sense to everyone else. _______________________________________________ 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]
