[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