[PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/23/2014 07:37 AM, Dan Wilcox wrote:
> On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
>
>> Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
> Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.

This is probably naive, but wouldn't it suffice to have an object that 
does automatically what the user is forced to do manually atm?

Manual -- user opens a Pd instance for GEM and a separate Pd instance 
for audio
Auto -- user creates an object [foo-audio-magic somepatch.pd] which 
automatically fires up a separate instance-- _not_ a child of the 
first-- for the audio.

>
>> Also, what is the metric to use here?
> Mmm open a larger patch with audio running, momentary dropouts.

How do you know that's due to Pd's single-threadedness, and not some 
CPU-hogging object, or a poorly optimized object chain, or Pd doing GUI 
calculations in the core thread as well as tk's thread?

>
> Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc

That particular problem is due directly to *_getrect calls in a patch 
with lots of objects (and possibly a bunch of *_click calls if hovering 
over an object that does a lot of computation in such a function).  It's 
not super easy to solve, but it's approachable because the Pd-GUI 
already exists.  But that's a completely separate issue from getting 
something like GEM to run in its own thread.

>
> Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.

It's not acceptable, but if you want to move forward _and_ do work that 
will be in sync with or accepted into Pd vanilla I don't see a way 
forward.  I can't even get help docs into Pd vanilla, and they were 
written to the PDDP spec that this community came up with and approved.  
And as you know, there's a publicly viewable list of the same exact 
frustrations from all kinds of developers with various styles of 
communication.

>
> At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing.

Did you use any of the Pd-l2ork versions before it moved to Tkpath? It 
didn't solve the *_getrect problem I mentioned above, but it solved a 
whole lot of the problems that cause dropouts while editing, mainly by 
shooting way fewer messages across the socket.

Anyway if you're interested in coding anything up related to this 
thread, I know Ivica is interested in solving the GEM issue you mentioned.

-Jonathan

>   Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
>
> enohp ym morf tnes
> --------------
> Dan Wilcox
> danomatika.com
> robotcowboy.com