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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
