[PD] pix_film more questions

[Roman Haefeli]

On Sat, 2007-02-17 at 12:58 -0600, chris clepper wrote:
> On 2/17/07, Roman Haefeli <reduzierer at yahoo.de> wrote:
>         
>         > The metro is not so hot in Pd either.  Good luck.
>         
>         here we go again. we already had a discussion here about that
>         topic
>         without a satisfying conclusion (at least for me). what
>         exactly do you
>         mean by 'not so hot'? is it inaccurate when using it to draw
>         something 
>         on the screen? if so, why?
> 
> Pd's logical time ignores real world 'wall time' and it also queues
> events.  That is fine if you only deal with time inside of Pd, assume
> that time is perfect and want every event to fire no matter how wrong
> the time is, but it causes trouble with any media reliant on 'wall
> time'.  Using a metro to drive pix_film will cause the media to drift
> from reference over time since events are not dropped if they do not
> arrive on time.  The correct handling would drop the event if it did
> not occur in the proper window and move on thus keeping proper
> relation to actual time.  

ok. but everything you say has nothing to do specifically with [metro],
but with the design of pd. [metro] itself is working ok and as expected
(like many example patches of frank show).

> The original pix_record used Pd's logical time and made recordings
> with completely wrong timing.  After adding internal timers pix_record
> would properly drop frames and adhere to a wall clock.  The windows
> version still has some problems with timing and will make some
> Keystone Cops footage if he load is extremely high.
>  

hm. i can see why someone would rather pd/gem have to drop one or the
another frame, if cpu-load is too high, when playing a movie-file,
instead of playing each frame in order, while losing timing. but why
would someone want [pix_record] to drop frames, while recording? i see
it as a big advantage of pd, that in a case, where a patch is too heavy
in cpu-load, you still could record an audio-file using [writesf~],
which might take a longer time than realtime, but you'll have for sure a
click-free audio-file as a result. why would someone want to have a
different behaviour for video?

roman 




		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de