Roman Haefeli wrote:
On Fri, 2008-02-29 at 12:30 -0800, Dudley Brooks wrote:
chris clepper wrote:
[gemhead 99] | | [pix_snap]
Of course! Ingenious!
However ... I tried it, and, even though the frame count output of pix_record churned out frame numbers, the resulting file was only one frame long and that frame only showed one of the geos. I even made the priorities of the various geos' gemheads explicitly lower and it still didn't work.
I can't figure out why that particular geo registered -- none of the geo's were connected to pix_snap. That's the intention, right?
actually they don't need to be connected. you can have all the geo stuff attached to a different [gemhead]. important is only the order of execution. first all geos need to be rendered and _after_ that you make a snapshot of the current buffer. that is why chris clepper is suggesting to use a [gemhead 99] (the higher the number, the later the according [gemhead] is drawing).
Thanks. That's what I suspected. Thanks for substantiating.
I also tried connecting several of the geos to pix_snap and the results were still the same: the movie had only one frame,
you have to send a 'snap' message to [pix_snap] for each frame you want to capture. usually this is done with something like:
[gemhead 99] | [t a b] | / | [snap( |/ [pix_snap] |
My error. I had thought that you meant that the signals from [gemhead 99] would *take the place of snap*. Your solution solves *half* the problem -- the movie now has the correct number of frames, but they're all identical to the first frame. However --->
(actually i am not sure anymore about the order: whether 'snap' or the gemlist message should be received first)
[t b a] turns out to be the one that works. Possibly that makes consistent sense? You'd want the gemlist to be "available" (whatever that means in this context -- the buffer?) first, before sending the message to snap it, right? I dunno. But it works!
which contained only one geo -- even when that particular geo was the only one which was *not* connected to pix_snap. So the connections were irrelevant.
exactly, they _are_ irrelevant. geos are drawn to the framebuffer and [pix_snap] captures a snapshot of the buffer, which means there is no connection needed.
Again, thanks for confirming my suspicion.
I assume it has something to do with rendering/buffering, but I don't know enough about those.
i hope it rather helps than it confuses, but for me it was important to understand, that Gem doesn't really reflect the dataflow paradigm: unlike in pd's audio connection, not the data itself is 'flowing' through the connections. rather Gem's object classes are used to compose instructions for the graphic card. those instructions are passed through all objects (actually only a pointer is passed around) and then the instructions are sent to card, where all the geos, textures and stuff are drawn into the buffer. when all the calculations are finished, the content of the buffer is displayed in the gemwin.
Thanks for the info. I guess a certain abstract data is still flowing (the "data" being "do this calculation") but I appreciate the help on understanding the time structure of the process.
(@devs: please correct me, if i am saying bullshit...) yo...having said, it might be easy now to understand a few cool tricks in Gem. for example, you don't necessarily need several geo objects (e.g. [cube]) in order to draw several of them. you could draw as many cubes with only one [cube] by passing more than one gemlist message per tick to it (a.k.a multiplying the number of instructions):
[gemhead] | [t a a a a] | / / / [rotateXYZ 2 4 6] | [translateXYZ 0.2 0.1 0.3] | [cube]
Thanks. That answers a question I hadn't yet submitted to the ng. I *could* ask for more details -- like how to give the multiple instances different characteristics, how to create a random (or at least not hardwired) number of instances, etc. But that would be a brand new thread, and I'll experiment with it first before asking for help.
i hope that sheds some light on your questions.
Absolutely! Thanks Roman, Chris, and Marius, for the help! And it's still in time to make my DVD and send it in by the deadline tonight!
-- Dudley