Hi all! I'm a long-time Pd user, but now I'm not-so-gingerly dipping my toe into the lunacy that is GEM.
I've attached what I hope is an exciting and useful patch. Through a lot of trial-and-error, I was able to figure out how to make an arbitrarily-sized grid of circles using a few of ClaudiusMaximus's recursion techniques. I still don't exactly understand what's going on, though, which is one of my main complaints about GEM... it's so opaque as a dataflow language!
Anyway, because I wasn't able to get Gridflow to work on my system, I went about trying to color this grid of geos according to a live video input without it. Miracle of miracles, it somehow works. But, thinking that since I was able to manipulate the color of individual geos, I should be able to do the same thing to their translations and rotations using the same gem chain.
But no. When I tried manipulating the Y-axis rotation of the individual circles (to signify brightness corresponding to the grey output of [pix_data]... viz. skinny side toward the viewer at 0 and face-on at 1) I could not for the life of me get it to make any recognizable sense as a raster. It's detuned, so to speak. I tried throwing all imaginable combinations of [separator] and [t a a] at it at various points, to no avail.
On the upside, the recursive results of such manipulations are incredibly interesting. The patch annotations gives you a few ideas to start.
I imagine somebody with more experience, or who understands OpenGL as a scripted language, might be able to shed some light on this question? Please?
Also, can somebody please explain to me why it is more useful for the x-y-position for [pix_data] to be scaled from 0 to 1 instead of the actual pixel dimensions of the image? I can imagine some reasons why, but it would be much simpler in in many cases to work in pixel addresses, instead of arbitrary floats...
Note: this patch makes use of [nrepeat] which seems to exist only as an abstraction somewhere in Claudius' recursion tutorial.
