Okay, done that and it did improve stability. However, I've now got
a little bit more javascript code in place and the instability is
back, although not quite as bad as before. I've attached the
composition again - this time, just opening the viewer showing and
closing the viewer window a couple of times is enough to kill
quartz composer.
I'm thinking that any further Adventures in Javascript are going to
be an exercise in patience (and frequent saves!) until there's an
update to the quartz composer framework that addresses this
instability. Is anyone else experiencing similar problems? I do
understand that the main focus of quartz composer is the graphical,
non-programming side of things and why, in the short term, JS
probably isn't all that high in the list of priorities.
It's important to send crash logs to Apple when the Crash Reporting
Dialog appears
1- If the javascript contains functions, is it necessary to
separate these somehow from the 'main' part of the code? (I believe
the answer is no).
Not sure what you mean, but the answer is likely no
2 - The javascript tool does not get executed repeatedly unless it
has connected inputs. In the attached composition, if the LFO is
removed then the javascript is called only once. Which I think is
wrong - as I understand it, a patch should be executed whenever a
dependent patch requests data from it - with the added
complication that data required by a published input to a macro
patch would cause the patch feeding the macro patch to be called
just once per frame, even if the macro was of the repeating variety
and effectively uses the data many times?
Behavior is correct: processor patches are executed if their outputs
are needed AND (their inputs have changed since last time OR the
patch depends on the time, and the time has changed)
JavaScript does not depend on the time. If you want it to depends on
it, just a connect a Patch Time patch to it.
3 - Performance - This composition, which is really just a few
cubes spinning round in space, seems to put a heavy load on the
computer. The load indicator in the viewer window moves from 35 to
70% - this is on a 1.67 powerbook. I've experimented with taking
out various patches and it does seem to be the cube that has the
heaviest impact on performance.
Cube patch is not very efficient for bulk drawing: it does quite a
bit of setup and cleanup. When you attempt to draw 160 of those, I'm
not surprised performance starts to drop.
You can try removing their textures - it might help though.
