<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Miller :)<div>Im running two instances of PD, and the one which is behaving strangely is the one which has no sound, DSP off : it is 0.43.4 extended on a recent Mac (10.9.2). This instance of PD runs mainly sensor analysis via GEM and sound high level control stuff, and, in this process, big CPU load comes from non permanent GEM blob analysis.</div><div>This PD instance deals with another PD running in parallel for making sound. For historical reasons, the other instance of pd is an earlier version 0.42.5 , using 8 channels with no driver (core audio).</div><div><br></div><div>The metro drift does occur if I run the PD Gem instance only, for a short while, and then returns to a correct behavior</div><div>Seems to be quite dependent on the overall load and on the power of the computer (duration of the ‘<b>short while</b>’) :</div><div>on mini mac, serious drifts (stress memory) for long time, can even stick false, on mac book pro shorter drift.</div><div><b><br></b></div><div><b>Gem instance running alone <u>or</u></b><b><u> </u>in parallel with other PD instance</b></div><div>DSP 140<span class="Apple-tab-span" style="white-space:pre"> </span>metro 1000 output 1450 msec</div><div>DSP 30<span class="Apple-tab-span" style="white-space:pre"> </span>metro 1000 output 430 msec <span class="Apple-tab-span" style="white-space:pre"> </span>happens for a <b>short while</b> (some seconds)<span class="Apple-tab-span" style="white-space: pre;"> </span>then</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>metro 1000 output correct (999/1001)</div><div><br></div><div><div>cheers<span class="Apple-tab-span" style="white-space: pre;"> </span></div></div><div>JM</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><div>Le 28 juin 2014 à 20:51, Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite">I've seen this happen lnog ago but not in the past several years at least - the<br>cause is probably that the audio driver on your machine is trying to make up<br>for lost time somehow. (Pd uses audo sample I/O to measure time). If you<br>aren't usng audio you can jsut turn DSP off to force Pd to use the system<br>clock instead of audio and this should make the problem go away.<br>On teh other hand if you need audio I/O on, it migth work to change the<br>audio drver (e.g., ise jack if you weren't before, change audio hardware, etc.)<br><br>By the way, what OS and hardware are you using? (and which Pd)?<br><br>cheers<br>Miller<br><br>On Sat, Jun 28, 2014 at 03:42:23PM +0200, <a href="mailto:jma@jeanmarie-adrien.net">jma@jeanmarie-adrien.net</a> via Pd-list wrote:<br><blockquote type="cite">Hi List<br>I have to solve the right way now clock drifts that result from the load of the CPU, because on my recent patches the CPU load varies dynamically enormously, resulting in time measurements totally wrong :<br><br>with a very high CPU load the metro 1000 object gives outputs twice too slow, and when bypassing some part of the patch dynamically, reducing the load drastically, the metro runs faster than twice to fast !<br>why does not pd come back to a reasonable time behavior when reducing the CPU load ? it seems that pd stays crazy because of former stress…<br>what is the correct way ? <br>- make a customized metro with the realtime object ? <br>- take CPU load in real time to scale logical time measurements accordingly across the patches ?<br><br>JmA<br><br><br>_______________________________________________<br><a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a><br></blockquote><br></blockquote></div><br></div></body></html>