 |
The central source for quartz composer creations.
|
| View previous topic :: View next topic |
| Author |
Message |
Dan Neuman
Joined: 27 Nov 2005
Posts: 8
Location: Ottawa, Canada
|
 Post subject: Persistent Memory in JavaScript Patch |
 |
|
(I moved this from the General section, since this seems a more applicable section.)
Not being a Javascript developer, it took me a while to discover this, but if you want memory that persists between patch iterations, you can get it by adding properties to the Math or the Object object.
| Code: | if(Object.x == undefined) {
Object.x = new Array(2); //initualize variable
Object.x[0] = 0;
Object.x[1] = 0;
}
Object.name = "My Name" //the variable gets created at the same time
Object.x[0] += inputs[0];
with(Object) {
outputs[0] = x[0]; //running total of input
outputs[1] = name;
}
|
Unfortunately, it is local to that particular JavaScript patch. Even the this object is local to the patch, so you can't use these variables to communicate to other patches. Better than nothing, though.
Things to remember:
First, if no inputs to the JavaScript patch change, then the patch won't change after the first run. So you'll need some varying input, whether you use it or not. I used the Patch Time patch.
Second, the persistent memory persists even if you stop the composition! So if your initialization code depends on inputs that the user might change in options (e.g. screen saver), either run the initialization during the first few milliseconds of Patch Time, or test for an uninitialized local variable.
Edit: Replaced the this object with the Object object.
Last edited by Dan Neuman on Thu Feb 16, 2006 12:45 am; edited 1 time in total |
|
Fri Dec 09, 2005 1:05 pm
 |
|
|
Dan Neuman
Joined: 27 Nov 2005
Posts: 8
Location: Ottawa, Canada
|
| Post subject: |
|
|
| Quote: | | So if your initialization code depends on inputs that the user might change in options (e.g. screen saver), either run the initialization during the first few milliseconds of Patch Time, or test for an uninitialized local variable. |
D'oh! You can't test for an uninitialized local variable since they get reset with every iteration. Since all user input must come into the JS patch through one of the inputs[i] variables, I keep a persistent copy of the user input, then test it against the inputs[i] variable to see if anything has changed.
| Code: | if((this.user_var == undefined) or
(this.user_var != inputs[1])){
this.user_var = inputs[1]; //save user input
//(re)set your other persistent variables here
} |
|
|
|
Mon Jan 09, 2006 6:14 pm
|
|
|
Dan Neuman
Joined: 27 Nov 2005
Posts: 8
Location: Ottawa, Canada
|
| Post subject: Avoid the "this" object |
|
|
| Turns out using the this object within the with () {} block will cause the JavaScript patch to crash. It doesn't seem to be a problem with the Object object. I think this would be preferable to using the Math object to avoid confusion between using Object variables and Math functions. |
|
|
Thu Feb 16, 2006 1:01 am
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
