[PD] libpd separating gui from core

[Jonathan Wilkes]

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.

Actually even in 2d without audio the problems manifest themselves 
pretty quickly.  For example: open the svg tiger inside Inkscape and 
move it around.  Notice the clever trick-- the image is broken into 
tiles and moved starting with the pieces closest to the mouse. Since the 
user's eye focuses on the mouse pointer, the interaction looks snappy 
even though it may take half a second or more to finish moving the tile 
furthest from the pointer.

When you add realtime audio the options are either to err on the side of 
sluggishness or to be responsive and risk dropouts.  If you want it to 
be responsive in both video and audio then you have to start doing some 
serious optimizations based on what you think the user cases are for the 
software.  For example, the Inkscape trick is perfect for creating and 
manipulating vector graphics, but it would be terrible for a 2d 
animation environment where you'd presumably want the tiger to move as a 
single unit.

However, many of Pd's current problems don't have a lot to do with 
that.  Tk is pretty good at being sluggish and avoiding dropouts when it 
doesn't have idle time to do graphics updates.  In fact I can move 
around an svg tiger on a canvas without interrupting the "test audio" 
patch.  Most dropouts related to the GUI have to do with what amounts to 
a DDOS attack from the core to the GUI.  When you flood tcl with data 
from the socket it can't really do anything else but spend time 
receiving it.  When you add that to whatever Pd core is doing to 
generate all those messages in the first place, you probably won't have 
any time left over for delivering audio.

Other toolkits are certainly more efficient than Tk.  But if you're 
dragging an antialiased wire from the top left of the window to the 
bottom-right, the toolkit needs time to do those redraws.

Finally, I'm not really sure how Open-GL and hardware acceleration plays 
into all this. For example, Qt Graphics View docs have a note about 
accelerated graphics possibly adding a performance hit and possibly more 
latency, but it's only in the context of hardware that doesn't do 
floating point computations efficiently.  I played around with Kivy a 
bit, which is hardware accelerated but honestly didn't see much of an 
improvement in cpu usage over comparable stuff in Tkpath.

-Jonathan

>
>
> cheers,
> Rich
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140219/2742892c/attachment-0001.htm>