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

Roman Haefeli reduzierer at yahoo.de
Fri Feb 29 23:03:05 CET 2008


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).

> 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]
|

(actually i am not sure anymore about the order: whether 'snap' or the
gemlist message should be received first)

> 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.

> 
> 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.
(@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]


i hope that sheds some light on your questions.

roman



		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de





More information about the Pd-list mailing list