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