[PD] GUI overload

Miller Puckette msp at ucsd.edu
Fri Dec 21 01:00:47 CET 2012


OK... I've pushed a change that seems to have fixed the arrays-atop-updating
problem (at lest in the Brane example).  Not sure if I should also commit the
  return (sys_domicrosleep(0, 1) || sys_poll_togui())  ---> + change
as well (somehow I think it should never be necessary to do that but I'm
realizing how little I understand Pd's scheduler.)

cheers
M

On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote:
> 
> It seems that there are a number of issues here:
> 
> * GUI objects sending every update, regardless of change (fixed)
> 
> * arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected
> 
> * all GUI activity stopping related to:
>   return (sys_domicrosleep(0, 1) || sys_poll_togui())
> 
> 
> * GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms.
> 
> * some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime
> 
> .hc
> 
> On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
> 
> > OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
> > 
> > Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
> > 
> > Ed
> >>  
> > 
> >> 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/
> >>>>> 
> >>>>> 
> >>>>>> _______________________________________________
> >>>>>> Pd-list at iem.at mailing list
> >>>>>> UNSUBSCRIBE and account-management -> 
> >> http://lists.puredata.info/listinfo/pd-list
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Pd-list at iem.at mailing list
> >>>>> UNSUBSCRIBE and account-management -> 
> >> http://lists.puredata.info/listinfo/pd-list
> >>>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> Pd-list at iem.at mailing list
> >>>> UNSUBSCRIBE and account-management -> 
> >> http://lists.puredata.info/listinfo/pd-list
> >> 
> >> 
> >> _______________________________________________
> >> Pd-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> http://lists.puredata.info/listinfo/pd-list
> >> 
> 



More information about the Pd-list mailing list