[GEM-dev] loop-y question

[tigital]

On Monday, July 28, 2003, at 02:16  AM, Daniel Heckenberg wrote:
> I'm not at a machine with GEM installed at the moment so I haven't 
> checked
> the patch you sent... but I think I understand what you're trying to 
> do.
>
> I've done similar things by using [counter] and the bang to trigger 
> mode of
> [gemhead].  It's a bit ugly, but things look like this:
>
> [gemhead]
>   |
> [render_trigger]
>   |
> [counter 1 30]
>   |
> [t b f]
>  |   |
>  |   +------+
>  |          |
> [gemhead]   |
>  |          |
>  |          |
> [translateXYZ]
>  |
> [rectangle]
>
> This ensures that the render chain is triggered at the appropriate time
> (during the GEM render cycle) and does the necessary looping.  I've 
> left out
> the 0 and 1 to enable and disable the lower gemhead from triggering at 
> its
> normal time in the render order.

...hmmm, I don't think I'm getting this hooked up correctly:  at best, 
I simply get a kind of animation of a rectangle moving in the x 
direction...do you think you could send a patch?  Here's a simplistic 
sketch of what I'm trying to do:

cube		cube		cube
cube		cube		cube
cube		cube		cube

...so we basically have a "rectangle" made out of "cubes", and have the 
ability to change the properties of individual cubes, at least through 
some kind of general function (say, apply a sin() to the size of the 
cubes)...

> This would be nice if wrapped up in a [gemloop] object as you've been
> discussing.  I think that a counter style outlet is probably more 
> useful.
>
> I've also been wondering if it would be good to have another gemhead 
> which
> takes in a list of values of length n.  It would then render n times,
> passing out a value each time before it triggers the render.  Actually,
> you'd probably do it so that you could send sublists of length greater 
> than
> one out at a time... and allow the possibility of using a table/array 
> as the
> list source.   This would allow nice "asynchronous" multiple iteration
> rendering in GEM...

...this sounds good too:  time to hit the debugger ;-)

jamie