I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55736&atid=478070 Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you. .hc On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote: > OK... except that I don't know why this works yet... by which i mean, I > don't think it's possible that sys_domicrosleep(0 is returning 1s on every > tick unless teh GUI itself is sending hundreds of messages per second down > to Pd. > > Reducing the average volume of trafic won't solve the underlying problem, it > will just make it harder to recreate it :) > > M > > On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote: >> >> I've seen similar things, like with the patches that Porres submitted. It >> looks like what's happening is that when there are too many updates being >> sent, a lot of them get dropped. Its pretty easy to get 250k per second of >> Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and >> compiler. The solution is to reduce the amount of Tcl code that gets sent >> and >> also use Tcl procs to handle bigger chunks of stuff so that we can take >> advantage of Tcl caching parsed and compiled procs. >> >> .hc >> >> On 12/16/2012 01:47 PM, Miller Puckette wrote: >>> This is just a guess... in s_inter.c, try replacing: >>> >>> int sys_pollgui(void) >>> { >>> return (sys_domicrosleep(0, 1) || sys_poll_togui()); >>> } >>> >>> with: >>> >>> int sys_pollgui(void) >>> { >>> return (sys_domicrosleep(0, 1) + sys_poll_togui()); >>> } >>> >>> It's possible that sys_domicrosleep(0 - which polls for input from GUI and >>> other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() >>> never >>> gets called. >>> >>> I've also seen a patch's GUI stop updating, but rather than bewail the fact >>> that my GUI was dead, my immediate reactions was to be astonished that the >>> sound was still working :) >>> >>> Miller >>> >>> On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: >>>> Hi List, >>>> >>>> I'm not going to say whether this is a "recurrent" problem as it's hard to >>>> say whether the rewrite of the GUI has affected it... >>>> >>>> I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I >>>> find the following problem occurs. There comes a point where the GUI >>>> objects stop responding in a patch when it is reloaded. I am wondering if >>>> there is a specific limit to GUI objects that could be changed. I think Pd >>>> is making some kind of decision that "there's too much of this stuff - I'm >>>> gonna prioritize the audio and not worry about it" and I'd like to know >>>> how or if it is possible to control this process from within Pd, or by >>>> setting flags on the command line. >>>> >>>> I'm also making less GUI intensive versions for performance time, since >>>> the really big GUI patches are often pattern-sequencers which I will not >>>> want to program when I am performing. Example patch enclosed to give you >>>> an idea. The really GUI-intensive objects are the trackers, especially >>>> quadtracker (which I think has pushed the GUI of Pd patches about as far >>>> as I can go now). >>>> >>>> System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of >>>> externals compiled and loaded. >>>> >>>> Warm wishes, >>>> Ed >>>> >>>> Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! >>>> http://sharktracks.co.uk/ >>> >>> >>>> _______________________________________________ >>>> [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 >>> >> >> _______________________________________________ >> [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
