Iterating an Integrator

bAjA's picture

I seam to have come across a bug - which is that a Integrator does not work inside a Iterator (not so surprising as the iterator is half the patch it used to be since snow leopard)

Was wondering if anyone could confirm this limitation and in an ideal world was hoping someone will have a work round, or point me in the direction of the make integrators work in iterators checkbox.

Would it be possible to build a integrator with a sample and hold and maths patch ? or with java if i knew it...

See attached test composition where if things where working as expected the sprites would be moving at different speeds.

Cheers - bAjA

PreviewAttachmentSize
itrated-integrator.qtz3.47 KB

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

usefuldesign.au's picture
Re: Iterating an Integrator

Just so your not unnesscarilly disappointed with SL, Integrator patch doesn't play well inside Leopard's iterator. Hopefully 10.7 will lion this out ;)

I've just rediscovered Integrator myself recently. I love it for solving some curly timing issues I can't solve with interpolation patch.

gtoledo3's picture
Re: Iterating an Integrator

I'm curious what inspires that comment that the iterator is half the patch is was.

bAjA's picture
Re: Iterating an Integrator

On a number of occasions the iterator has run super slow doing what should be a simple task - one that i can remember was using a multiplexer to switch images. I'm also sure i have read of other people have issues...

But I except my statement was a little dramatic, perhaps I was trying to add a little spice to pretty boring topic. I apologize to any iterator lovers I have offended.

So i managed to make a integrator from a maths patch and a sample and hold, but it would seam that sample and hold suffers the same fate inside an iterator and refuses to work.

Can anybody come to my help with a little java script ?

gtoledo3's picture
Re: Iterating an Integrator

I was just curious if it used to run better on those activities on Leopard for you. I thought the "half of what it used to be" was interesting. I don't know that I find that to be true.

Why don't you try using a patch time connected to a multiplexer with two inputs, and enable it when you need to. I think a Stop Watch should work fine in an iterator as well. Counter works, as does sample and hold (yeah, it does work in an iterator). Maybe you should just post your malfunctioning composition?

bAjA's picture
Re: Iterating an Integrator

ok here it is, in its single form- just one arrow wandering about and I would like to use an iterator to turn it into an army of arrows..

also here is my attempt at iterating it using sample and hold instead of an integrator.

PreviewAttachmentSize
arrow-wander.qtz29.4 KB
arrow-wander-iter.qtz31.86 KB

usefuldesign.au's picture
Re: Iterating an Integrator

You can just use an Input Splitter to hold/pass an output value back to an input port on same patch. That's not important… just thought I'd mention it.

Basically you are using the integrator in a way i don't get the logic of (not saying it's wrong: I just don't get it). Integrator Patch provides the integral function for a simple time based function as in velocity in —> displacement out. So the input is dt time and value sensitive. See attached Gravity comp and adjust values or even move a patch in Editor to see how the mechanics is disturbed very easily.

I would avoid this approach altogether in your composition unless you know how to calculate the integral in a maths expression of whatever movement (mechanics) functions you want to use using time based calculations not adding to existing values, it's to wonky for my liking.

Examining this comp has thrown up a few things for me. Finally have a good use for KinemeCore pause (use menu command, the shortcut is buggy) and step viewer controls (shortcuts ok)!

This is a great example of why I don't like doing too much logic inside the iterator. It's a nightmare to debug. I'd get values outside and either queue them in or use JS Patch to make a structure of values. Observed some interesting things about how the Iterator Patch executes JS patch using Log statements which you can enable. Just don't go into debug mode for the output enable Graph Foundation Log in hidden preferences (Option key + Preferences menu) or Console.app. Debug-mode ground my Mac to a halt inside the iterator.

I did find another patch failure along the way with this. I often use the iterator vars. position output to drive sprite colour via the HSL generator patch. When I put them and an interpolate into a Macro for neatness the Hue input defaults to zero. I'm on Leopard not sure if it bugs out on SL too. See Comp to test.

If you divide by 1 instead of 1000 you know where it gives interesting results. It's weird how sometimes all the angles are identical and sometimes they are all different and sometimes some of them are the same and some are different. They kind of lock off for a while. Not sure why at all. I can't quite get my head around the logic behind your equations.

I'd be calculating all the positions in maths expression or JS patch. You know your trig so no sweat there.

PreviewAttachmentSize
arrow-wander-iter II.qtz35.52 KB
Gravity.qtz31.3 KB

cwright's picture
Re: Iterating an Integrator

There's a radar on this already (fyi)

gtoledo3's picture
Re: Iterating an Integrator

Did this used to work?

cwright's picture
Re: Iterating an Integrator

never

usefuldesign.au's picture
Re: Iterating an Integrator

cwright wrote:
There's a radar on this already (fyi)

Is that a blanket Patch [a,b,c,…] doesn't work in iterator radar? Would it include the thing I mentioned about putting the HSL Patch in a Macro inside Iterator Patch and having it die on you?

I noticed quite a bit of weirdness going on in that comp besides death of the Integrator patch… that's why I'm asking.

cwright's picture
Re: Iterating an Integrator

usefuldesign.au wrote:
Is that a blanket Patch [a,b,c,…] doesn't work in iterator radar?

No, it's quite literally integrator-specific.

usefuldesign.au wrote:
Would it include the thing I mentioned about putting the HSL Patch in a Macro inside Iterator Patch and having it die on you?

HSL isn't stateful, so it won't break inside the iterator. However, if upstream things aren't working, downstream things will appear to malfunction as well.

usefuldesign.au's picture
Re: Iterating an Integrator

cwright wrote:
HSL isn't stateful, so it won't break inside the iterator.
What does that mean? (that's a genuine question: I don't know how stateless/stateful specifically applies to QC patches). Which patches are stateful? There are Sample & Hold patches in the non-iterator version bAjA and I posted and JS patches in mine.

cwright wrote:
However, if upstream things aren't working, downstream things will appear to malfunction as well.

Two things: There's nothing upstream of the HSL except for It Var patch. Unless you mean patches upstream of (common) downstream renderers — which is essentially all patches in this case.

For an isolation of HSL bug please see attached comp (10.5).

The other thing is there are no integrators in the second comp arrow-wander-iter.qtz posted by bAjA (nor the one I posted which contains additional JS patches are they stateful?). So if it's a case of something else breaking the whole iterator what is actually breaking it?

PreviewAttachmentSize
HSL in Iterator.qtz6.33 KB

gtoledo3's picture
Re: Iterating an Integrator

The Iterator Variable patch needs to be used inside of the Iterator. When it's placed inside of another macro level it doesn't reference the Iterator anymore, and loses it's infinite execution time. It's not a failure of the HSL patch. If you publish patch time on your Interpolation patch and connect it to one of the Iterator Variable that is inside of the Iterator, it will start working how you expect it to again.

The way I read the patch description of Iterator Variables makes me think that it has to be directly inside of the Iterator, but that may be a leap on my part.

I'm curious what cwright has to say of course, and I haven't looked at the other stuff. Not trying to chime in out of turn, just looking at what seems to be wrong...

usefuldesign.au's picture
Re: Iterating an Integrator

Not out of turn at all, I guess that explains the HSL issue I was having, is in fact a Iterator Variables stipulation. To be honest I wondered about that aspect of it and I thought I tried porting the value in (but obviously I didn't actually try it!).

That just leaves which Patch is actually breaking the iterator, maybe none at all!? (I'm not sure what it should be displaying).

toneburst's picture
Re: Iterating an Integrator

usefuldesign.au wrote:
What does that mean? (that's a genuine question: I don't know how stateless/stateful specifically applies to QC patches). Which patches are stateful? There are Sample & Hold patches in the non-iterator version bAjA and I posted and JS patches in mine.

'Stateful' simply means it has to maintain a value between frames. Smooth, for example, is stateful, because it needs access to the previous frame's value in order to calculate the current value.

a|x

usefuldesign.au's picture
Re: Iterating an Integrator

Thanks, toneburst . I guess I'm asking if stateful patches have issues in QC, what issues? Is it just inside iterator the confusion occurs and is it all stateful patches that are flakey inside. That's why I mentioned the S&H and JS patches — stateful by definition in case of S&H and JS is multi-valently stateful.

JS seems designed for special iteration savy use in the Iterator Macro (as I recently discovered thanks to the QC-list work of Franz and confirmation by gtoledo). I suspect the S&H is misbehaving in that comp because all the iterations are locking off to the same Z-Rotation angle at times.

cwright's picture
Re: Iterating an Integrator

What gtoldeo3 and toneburst said.

So basically, an upstream patch was breaking, which caused HSL to apparently break. I specifically mentioned that failure case being misleading (and iterator variables not working inside a macro inside an iterator is a well-known arbitrary limitation -- I think you even filed a radar on that issue?)

usefuldesign.au's picture
Re: Iterating an Integrator

Oh yeah that rings a bell : ) <I'm a QC shift worker who's constantly relearning the finer points>

Okay I get your logic now (duh, I thought I detected some slight sarcasm the first time), then I got to thinking about the other patches in that iterator and thought maybe you were refering to them because S&H patch is stateful. Glad you cleared that up, thanks.

To summerise: ALL stateful patches will break inside iterator with the exception of Javascript patch and Queue in SL. Correct?

cwright's picture
Re: Iterating an Integrator

usefuldesign.au wrote:
To summerise: ALL stateful patches will break inside iterator with the exception of Javascript patch and Queue in SL. Correct?

incorrect. many 10.6 stateful patches were updated in 10.6 to handle iterators "correctly" (where correctly doesn't mean it's 100% right, but better than 10.5 where things just stomped on themselves -- the incorrect stuff happens due to some logical errors in iterator execution itself, not the patches, and generally only happens if you change iteration counts on the fly, and only then if you decrease counts).

on 10.5, there was no hope of this working correctly. You could make a JS patch that took the current iteration input, and did the right thing, but that's the only exception. Everything else doesn't work.

usefuldesign.au's picture
Re: Iterating an Integrator

Cheers. Thanks for the comprehensive insight too – much appreciated.

toneburst's picture
Re: Iterating an Integrator

I imagine all stateful patches will eventually be made 'iterator-safe'. It's a matter of maintaining discrete states for each instance of the patch inside the Iterator.

a|x

gtoledo3's picture
Re: Iterating an Integrator

I was thinking about your composition.

This is a different approach that gives a similar type of look.

I'm using a rotation calc based on atan2(x,y). You could just randomize and smooth your rotations, kind of like you do in the sample. This would keep the arrows from pointing "down" when Y is less than zero. I also added in some color fade/iteration to make the arrow dissolve as it goes offscreen.

Hope this helps.

There is a noise object that generates.... noise...when you feed it with x/y and/or z, that works in an iterator, in addition to the random patch to make this come together.

It's somewhat "not" random in that I'm using LFO's to set up base movement, but I'm randomizing aspects of the LFO, adding the Noise in, and also powering with System Time.

I don't claim this to be finely honed or anything, just illustrating a point.

PreviewAttachmentSize
food for thought.qtz58.46 KB

bAjA's picture
Re: Iterating an Integrator

Cheers Mr Toledo for giving this some thought, just when i thought the discussion had moved on the inner working of iterators. Thats an interesting patch - but i'm not sure what you have done fulfills my original aim. This was to create sprites that point in the direction which they are moving. (which i accept i did not spell out). Infact the final goal is to replace the arrow image with an animation of an ant, that will change direction on an audio trigger. The tip of using system time instead of patch time to create unique animations on each run is appreciated and i will use and enjoy this in the future.

randall's picture
Re: Iterating an Integrator

I'm assuming this applies to interpolation as well... maybe I'll just rewrite my JS to handle the interpolation internally. Worth a shot, I guess.

I was trying to rewrite the built-in chart patch to automatically animate the height values on launch, and when changed.

Right now, it doesn't work. My first thought was the JS was failing, but having read, now my guess moves to the interpolation.

rb

PreviewAttachmentSize
Chartrb.qtz23.89 KB

randall's picture
Re: Iterating an Integrator

Realizing this also applies to the "sample & hold" patch too.

Blast.

How do you save state between frames in JS?

usefuldesign.au's picture
Re: Iterating an Integrator

Everything gets saved between frames. If you have declarations (eg: my_var = new Number(); ) in your code it will wipe my_var to null though.

So declare all vars you want to hold over to next frames before or outside the main function() definition and they become global declarations not main function declarations and only get run on the first two runs (including _testMode) of the Javascript patch.

usefuldesign.au's picture
Re: Iterating an Integrator

If you can supply xml data file and make this Leopard friendly I'll look at it. Not promising I can fix it though ;-)

> (null)
<QCNodeManager | namespace = "com.apple.QuartzComposer" | 715 nodes>: Patch with name "/split" is missing
 
> Iterator
Cannot create node of class "/split" and identifier "(null)"
 
> Iterator
Cannot create connection from ["Upper_Value" @ "Patch_1"] to ["inputValue2" @ "Interpolation_1"]
 
> Iterator
Cannot create connection from ["Lower_Value" @ "Patch_1"] to ["inputValue1" @ "Interpolation_1"]
 
> TrackBall
State restoration failed on node "Iterator_1" <QCIterator = 0x0EEBE2C0 "(null)">
 
> 3D Transformation
State restoration failed on node "TrackBall_1" <QCTrackBall = 0x0A3DAEE0 "(null)">
 
> Lighting
State restoration failed on node "Camera_1" <QCCamera = 0x0AA53460 "(null)">
 
> Macro Patch
State restoration failed on node "Lighting_1" <QCLighting = 0x0A507870 "(null)">
 
> (null)
State restoration failed on <QCPatch = 0x0AC48660 "(null)">

randall's picture
Re: Iterating an Integrator

Thanks so much!