[PD] GUI overload
Hans-Christoph Steiner
hans at at.or.at
Thu Dec 20 18:17:35 CET 2012
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