[PD] libpd separating gui from core

[Jonathan Wilkes]

On 02/20/2014 09:50 PM, Rich E wrote:
>
>
> On Wed, Feb 19, 2014 at 12:07 AM, Jonathan Wilkes <jancsika at yahoo.com 
> <mailto:jancsika at yahoo.com>> wrote:
>
>     On 02/18/2014 11:11 PM, Rich E wrote:
>>
>>
>>
>>     On Mon, Jan 13, 2014 at 5:35 PM, Dan Wilcox <danomatika at gmail.com
>>     <mailto:danomatika at gmail.com>> wrote:
>>
>>         Ah wait, duh. Of course the graph needs to know positioning,
>>         that's how it determines execution order or independent
>>         blocks of objects right?
>>
>>         On Jan 13, 2014, at 5:14 PM, Dan Wilcox <danomatika at gmail.com
>>         <mailto:danomatika at gmail.com>> wrote:
>>
>>>         Does the dsp graph rely on positioning? I thought only via
>>>         connections. I'd imagine the gui wrapper should only worry
>>>         about positioning and simply update those changes when saving.
>>
>>
>>
>>     IMO a separation between GUI and core could/would include
>>     position, e.g. objects have their connections mapped by an index,
>>     GUI assigns the index to the object based on position.  This
>>     would allow for some much more sophisticated GUI's, such as 3d,
>>     or even a more human-readable text version (json has been mentioned).
>
>     You run into problems when you want to get decent GUI interaction
>     _and_ expect to deliver audio to the soundcard in realtime.
>
>
> The GUI and audio shouldn't be updated from the same thread.  This is 
> one nice thing about libpd, it forces a separation.

What are the drawbacks to the multi-threaded approach? Specifically, for 
a full-fledged editing environment where you can't easily predict what 
the userbase is going to come up with inside the GUI?

>
> So in this type of world, the GUI can do whatever it needs to do in 
> order to draw at the desired framerate, and flags graph changes along 
> the way.

In Pd-extended and Vanilla currently there is very little optimization 
to get the most out of Tk.  Those problems have a tendency to get lumped 
in with single-threadedness.  So if someone actually gets something with 
a better design up and running, just remember that you have to do 
similar optimization work before the benefits of the new system really 
start to shine.  Otherwise you'll get burned out when the right approach 
still gets dropouts-- from the odd inefficient algorithm, some 
"standard" widget that eats CPU for lunch, or whatever else isn't 
documented on the shiny frontpage of the toolkit.

-Jonathan

>  The changes are then converted into a GUI-agnostic format and 
> synchronously issued to the audio context.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140221/507689d6/attachment.htm>