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, [email protected] 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 <[email protected]> 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, [email protected] 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 > >> > >> > >> _______________________________________________ > >> [email protected] mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
