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