[PD] Capture Gem output: best practices?

[cyrille henry]

Le 17/09/2017 à 21:07, Federico Camara Halac a écrit :
> Very interesting question, indeed.
> 
> I have only used Max's option A (pix_snap, pix_record) and they work fine. If CPU is at the limit, what I have done is just go via ethernet to a second computer, and do all video rendering and recording there, leaving the main one for audio only.
> 
> I have some more follow-up questions, though:
> 
>     then I record every image (not in real time) : it allows a very good recording quality,
> 
> Do you use pix_write for this, with larger window dimensions?
yes

> 
> 
> 
> 
>             A) inside GEM
>             You can record the GEM window inside GEM with pix_record and pix_snap. This is the cleanest and cross platform solution, because it doesn't require additional soft- or hardware. You can also render things slower than realtime, while making sure to save every frame.
> 
> 
> Do you also use the FSAA message? Does it affect pix_write / pix_record quality ?
pix write record the frame buffer, so it's affected by FSAA

> 
> Extra questions:
> 
> is "batch" mode an option for non-realtime recording ? or would it not work with Gem? I have never tried this.
batch mode allow to go faster than real time. In this situation it will not change anything since pd run slower than real time.

> 
> 
>     for performance, I record every fader and control, so pd can play the performance again.
> 
> How did you achieve this, in a simple text file like using [text], [text sequence], or something else?
yes.

I made a simple abstraction that I insert between every fader and what they control. The abstraction send value to the text file and receive data from the same file.

cheers
c
> 
> Cheers!
> 
> fd
> 
> 
> -- 
> http://fdch.github.io/tv