[PD] Saving Gem output as video file on MacOSX ?

[Dudley Brooks]

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