[PD] Timer / metro / realtime

[Miller Puckette via Pd-list]

Cool - once again I'm learning that Pd doesn't work the way I thought it did!

I thnk then you'll get teh behavior you want if you simply have the non-audio
Pd open an audio device for output (the mac built-in audio for instance).

Meanwhile, I'll have to think about how to get teh more 'corret' behavior
when running from teh system clock - I think I'd have to simulate a FIFO
underrun and "reset the FIFO" somehow for that case.

thanks for flagging this...
M



On Sun, Jun 29, 2014 at 10:18:13AM +0200, jma at jeanmarie-adrien.net wrote:
> Hi Miller :)
> 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.
> 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).
> 
> The metro drift does occur if I run the PD Gem instance only, for a short while, and then returns to a correct behavior
> Seems to be quite dependent on the overall load and on the power of the computer (duration of the ‘short while’) :
> on mini mac, serious drifts (stress memory) for long time, can even stick false, on mac book pro shorter drift.
> 
> Gem instance running alone or in parallel with other PD instance
> DSP 140		metro 1000 output 1450 msec
> DSP 30		metro 1000 output 430 msec   			happens for a short while (some seconds)	then
> 			metro 1000 output correct (999/1001)
> 
> cheers	
> JM
> 
> 
> 
> 
> 
> 
> 
> Le 28 juin 2014 à 20:51, Miller Puckette <msp at ucsd.edu> a écrit :
> 
> > I've seen this happen lnog ago but not in the past several years at least - the
> > cause is probably that the audio driver on your machine is trying to make up
> > for lost time somehow.  (Pd uses audo sample I/O to measure time).  If you
> > aren't usng audio you can jsut turn DSP off to force Pd to use the system
> > clock instead of audio and this should make the problem go away.
> > On teh other hand if you need audio I/O on, it migth work to change the
> > audio drver (e.g., ise jack if you weren't before, change audio hardware, etc.)
> > 
> > By the way, what OS and hardware are you using?  (and which Pd)?
> > 
> > cheers
> > Miller
> > 
> > On Sat, Jun 28, 2014 at 03:42:23PM +0200, jma at jeanmarie-adrien.net via Pd-list wrote:
> >> Hi List
> >> 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 :
> >> 
> >> 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 !
> >> 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…
> >> what is the correct way ? 
> >> - make a customized metro with the realtime object ? 
> >> - take CPU load in real time to scale logical time measurements accordingly across the patches ?
> >> 
> >> JmA
> >> 
> >> 
> >> _______________________________________________
> >> Pd-list at lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > 
>