On Mon, Oct 4, 2010 at 8:29 PM, Christopher Wright < [email protected]> wrote:
> In using javascript and the iterator, I've encountered a scenario where
> decreasing iterations doesn't seem to properly influence the output of the
> javascript.
> In this attachment, if the iteration count is decreased, the number of
> indices on the output does not decrease. Is this correct in function?
>
>
> _spread = []
> function (__structure spread) main (__structure iPosition, __index index)
> {
> var result = new Object();
> _spread[index] = iPosition;
> result.spread = _spread;
> return result;
> }
>
>
> 1) add a semicolon after []. (it's not strictly necessary, but it's good
> form).
>
Thanks, I appreciate that.
>
> 2) where are you unsetting dead indices? I don't see any logic in there
> capable of writing to _spread[N] where N > index. As such, decreasing the
> iteration count will decrease index's range, but will do nothing to change
> _spread's already-present members.
>
I'm not, and that's what I was unsure of. I have used the splice function to
do this with javascript in the past, but in this scenario I wasn't sure if
it should happen as a function of how many iterations there are, or if I
could expect this behavior to stay this way in the future.
> In light of item 2, I am of the opinion that this behaves correctly.
>
Thanks, it's uncharted territory for me so I was hoping you would add in
with your thoughts. I bring no opinion to the table on it.
This has several really cool implications.
For instance, the composition I'm attaching is set to just 1 iteration.
While at Index 0 one can set a point. Then, one can go to Index 1, Index 2,
and so on, with each time that the Index shifts, a structure getting stored.
One can set more and more points, without ever increasing iteration, or
inducing a FPS count on the Viewer (!).
I always thought that iteration count needed to be managed in these kind of
scenarios, and it's cool to see that isn't the case when publishing output
of an iterator like this.
I also notice, when you go "back" to an old index, whatever you do gets
written over if you change values and shift back off of the edited index.
You can also skip around in what index you want to store stuff at, without
having to store "in order". In messing with this concept for a few minutes
(past my attachment), it's an interesting way of doing
write/undo/redo/recall type activities in QC. With something like the queue,
you can recall an index of structure, obviously, but you can't go back and
write over that index since it constantly pushes through after it fills.
So, this is a really cool discovery to me that publishing out of an iterator
can work this way. Very awesome.
-George
Spread Generator Test_10_gt.qtz
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]
