I'd say the Easy fix is to use an RSS feed and a Javascript patch both
feeding into a Multiplexer. Feed your RSS data into the Multi, AND a
Javascript Patch, which just stores the data and passes it on.

Use the "Done Signal" on the RSS feed to switch the Multiplexer from the RSS
feed to the Javascript patch (when done of course), and the same signal will
tell the JavaScript patch to ignore Inputs[0].


/* The following stores an input in a global variable, when a condition is
true
*/

if (inputs[1] == true) {
  outputs[0] = this.foo;
} else {
  this.foo = inputs[0];
}

/* OK, I thought about this for a second, and realized that the "done"
signal would be the moment when the file is complete. So we want to have a
chance to sample it ONLY at that time. So I add a stopwatch that gets
triggered by the DONE signal; */

if (inputs[1] > 2) {
  outputs[0] = this.foo;
} else {
  this.foo = inputs[0];
}

I haven't tested it out, but I'm guessing this should work -- see the
attached image for the composition flow. You might do this with merely the
Javascript, but I've always treated the Multiplexer as a poor man's global
variable -- it caches the input stored there. So as long as there is no
change in input, the output should stay the same, and there should be no hit
on the RSS feeder.

There may be a way to tweak the Javascript Code, and have this.foo stay the
same in the JavaScript and not update after (inputs[1] > 3) -- that way
Quartz would interpret this as no new data. Not sure if just declaring
this.foo would overwrite the data if it wasn't given a value or not -- worth
a test.

-- Hope this helps!
Best of luck,
Mark Johnson

> The problem I'm suffering from is terrible performance. In each
> frame many patches are executing unnecessarily, since the RSS
> changes only rarely, and so all the decision logic / javascript
> patches used to generate inputs to each cube will evaluate to the
> same result.
>
> Is there any way to prevent this unnecessary execution? What I
> really need is some kind of "Latch" or cache patch that could be
> wired to the "updated" output of the RSS patch, so that unless there
> is new content, the cached content is provided to the cube inputs.
>
> I found this old thread which describes the identical problem back
> in 2005:
>
> http://lists.apple.com/archives/quartzcomposer-dev/2005/May/msg00130.html
>
> Unfortunately that thread didn't have a happy ending. I'm reposting
> the problem in the hope that someone else might have devised a way
> around this seemingly simple problem.
>
> Thanks in advance for any help anyone can provide.
>
> Cheers,
> -Brendan
>

Attachment: mutliplexer cache.png
Description: Binary data

 _______________________________________________
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]

Reply via email to