On 2/17/07, <b class="gmail_sendername">Roman Haefeli</b> &lt;<a href="mailto:reduzierer@yahoo.de">reduzierer@yahoo.de</a>&gt; wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>&gt; The metro is not so hot in Pd either.&nbsp;&nbsp;Good luck.<br><br>here we go again. we already had a discussion here about that topic<br>without a satisfying conclusion (at least for me). what exactly do you<br>mean by &#39;not so hot&#39;? is it inaccurate when using it to draw something
<br>on the screen? if so, why?</blockquote><div><br>Pd&#39;s logical time ignores real world &#39;wall time&#39; and it also queues events.&nbsp; 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 &#39;wall time&#39;.&nbsp; 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.&nbsp; 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.&nbsp; 
<br><br>The original pix_record used Pd&#39;s logical time and made recordings with completely wrong timing.&nbsp; After adding internal timers pix_record would properly drop frames and adhere to a wall clock.&nbsp; The windows version still has some problems with timing and will make some Keystone Cops footage if he load is extremely high.
<br></div><br></div><br>