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 something. I notice, though, that I can send a frame number while 'auto 1' is enabled and it jumps to that spot and keeps playing. I think this will suit my purposes, but I'm wondering if PD always gets the fps exactly right under auto. Obviously it wouldn't do to have me 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?
-Chuckk
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.
something. I notice, though, that I can send a frame number while 'auto 1' is enabled and it jumps to that spot and keeps playing. I think this will suit my purposes, but I'm wondering if PD always gets the fps exactly right under auto. Obviously it wouldn't do to have me
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 movie. i think you can consider this as a bug.
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.
mfg.asdr IOhannes
On 2/12/07, IOhannes m zmoelnig zmoelnig@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 movie. 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 rounding. 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.
Thanks IOhannes. -Chuckk
-
Chuckk Hubbard -
IOhannes m zmoelnig