Hmmm... I'll have a look. Thanks for doing the heavy lifting on this one! M
On Wed, Dec 19, 2012 at 09:39:02AM -0500, Hans-Christoph Steiner wrote: > > 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
