Persistent data across Quartz evaluation cycles ?

brettm's picture

first variant of the question: Is there a way in Quartz/Javascript to save data between/across calls to a JS function?

(other than using the Quartz Queue patch to save a structure) ( like some form of "static/global" variable ?)

second variant: Other than writing a plugin in Objective-C (where presumably All Things Are Possible) , is the Queue the only mechanism for persisting data across Quartz evaluation cycles?

Can Quartz read/write files?
( Slow, i know, but perhaps useful if non-realtime rendering is done )

cwright's picture
Re: Persistent data across Quartz evaluation cycles ?

First: stuff outside of the Main function in JS will persist across frames.

var count = 0;
function (blah blah) main (blah blah)
{
   result.frameCount = count++;
   return result;
}

Second: the Queue is the only other way of storing data across frames. well, sample & hold is another, but it's relatively limited (limited to a single value per frame).

(virtual) Third: No, QC cannot write to files on its own. There are plugins that accomplish that in varying amounts.

toneburst's picture
Re: Persistent data across Quartz evaluation cycles ?

Declaring the variables outside the main loop works in the JavaScript patch.

I thought at one point that a similar technique could be used to create feedback-type effects using JavaScript in a Core Image Filter patch, but sadly, it doesn't seem to be possible to have persistant __image variables in a CIFilter. Unless I'm missing something.

a|x

Lango's picture
Re: Persistent data across Quartz evaluation cycles ?

toneburst wrote:
I thought at one point that a similar technique could be used to create feedback-type effects using JavaScript in a Core Image Filter patch, but sadly, it doesn't seem to be possible to have persistant __image variables in a CIFilter. Unless I'm missing something.

Haven't checked this but from my mental model i'll say that it does in fact 'save' the value. However the value is just a memory reference (or pointer) to where the image is being stored. The space where the image is being stored may have been used for something else by the next frame.

Well, that's my thought, i might look into that if i get some time.

Cheers

EDIT: fixed typo