[PD] GEM pix_film/movie issues
badmuthahubbard at gmail.com
Mon Feb 12 19:57:35 CET 2007
On 2/12/07, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> Chuckk Hubbard wrote:
> > Hi.
> > I'm trying to set up Csound and PD together to score an animation.
> > When I have Csound send the frame numbers explicitly, the picture
> > bleeds all over itself, like some pixels not refreshing regularly or
> this sounds like a codec problem: with inter-frame compression this can
> happen sometimes.
Oh I see. Well chances are these animators will use Quicktime. I'm
not familiar with details of formats, as I understand it this
compression is more of an avi thing... I just tested on a huge .mov
file and it was fine.
> Gem definitely ignores the fps of the movie it loads in auto mode (at
> least on non-QuickTime (apple & m$) containers).
> it just uses Gem's internal fps and advances to the "next" frame in the
> i think you can consider this as a bug.
I recall seeing somewhere how to set Gem's fps, but I can't seem to
locate the info now. Could you point me towards it?
> > give the animators a soundfile that doesn't line up exactly on their
> > machines.
> > Is there any way for GEM to read fps from a file header, so it can
> > tell Csound in order to calculate starting points when I want to go
> > over certain sections?
> the 2nd outlet of [pix_film]/[pix_movie] gives you a list:
> "<#frames> <xsize> <ysize> <fps>" as found in the movie meta-data.
Is this new? I'm only seeing the first three.
One reason I'm leery of just looking up the fps and entering it
manually is that I've seen decimal values for fps, and I'm afraid of
Also, I was leaning towards sending frame changes as OSC from Csound,
but now that I think about it, Csound's control rate doesn't work the
same as Pd's block size, and the values would only be sent between
blocks of audio, as opposed to Pd which interpolates determined
control signals... Maybe Pd will have to do the counting.
More information about the Pd-list