I'm not sure but I believe it should work if you periodically call sys_domicrosleep(0, 1) - this asks it not to sleep at all but just to poll all the FDs Pd is watching.
cheers Miller On Sat, Jan 26, 2013 at 11:16:41PM -0500, Rich E wrote: > On Mon, Jan 21, 2013 at 11:30 AM, Thomas Grill <[email protected]> wrote: > > > Sorry, one more note: > > In libpd, sched_tick is currently calling in the PROCESS macro in the > > context of the audio callback (in z_libpd.c). > > The function sched_tick handles all timed objects (such as metro) and > > therefore triggers all kinds of message processing downstream, where also > > memory operations commonly happen. > > In this sense, calling sys_domicrosleep at the end of PROCESS does not > > make the situation worse than it is right now. > > > > gr~~~ > > > > > Why doesn't sched_tick call sys_domicrosleep then? > > That function is making sleep and lock calls that I don't think should be > made in libpd's process loop verbatum - timing is handled by whatever audio > callback mechanism is using libpd and locking is handled within the > language / framework wrappers. > > It looks like the meat and potatoes is the following funky guy: > > (*sys_fdpoll[i].fdp_fn)(sys_fdpoll[i].fdp_ptr, sys_fdpoll[i].fdp_fd); > > > If this were to be utilized by libpd, we should probably create a new, > barebones method that does this polling (whatever that is...). > > > cheers, > > Rich > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
