[PD] GUI overload

Hans-Christoph Steiner hans at at.or.at
Mon Dec 17 21:35:47 CET 2012


Seems like there is multiple issues going on here.  I've been working with
Porres' Brane-e patch, where the array updates while recording in 0.42 but not
in 0.43.  It seems that in 0.43, scalar_vis only gets calls once when the
recording starts, then again only after the recording has finished.

But now, in a bizarre twist, it has fixed itself in every Pd installed on my
system.  Before this problem used to happen every time with 0.43 vanilla and
extended.  Now it works everywhere, even on the binary packages, which I
definitely didn't change.

When I was able to reproduce the Brane-e problem, changing sys_pollgui()
didn't affect it either way.

.hc

On 12/17/2012 03: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



More information about the Pd-list mailing list