[PD] libpd separating gui from core

Jonathan Wilkes jancsika at yahoo.com
Mon Jan 13 23:05:46 CET 2014

On 01/13/2014 03:11 PM, Dan Wilcox wrote:
> Woops, forgot the reply-all.
> On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes <jancsika at yahoo.com 
> <mailto:jancsika at yahoo.com>> wrote:
>> On 01/13/2014 09:32 AM, Dan Wilcox wrote:
>>> As Hans has proposed for years, IMO this is really the only way to 
>>> perhaps solve the "PD gui development doesn't move fast enough" 
>>> problem in the long term. In this case, Miller would have the core 
>>> (in libpd) & the pd-vanilla wrapper gui formally separated while 
>>> everyone else can then use the same libpd core within other flavors. 
>>> The DSP core is the heart and soul and I see no reason to try and 
>>> change that in any way.
>> Sorry, I don't know quite what you're referring to here. The only two 
>> examples I gave-- $@ and [initbang] wouldn't change anything in the 
>> DSP core.
> I wasn't referring to anything in particular, only in general.

Then what do you think of "$@" or [initbang]?  Are there good reasons 
for them not being in the core?  What about infinite undo? Or symbols 
that don't cause memory leaks?

>>> On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <jancsika at yahoo.com 
>>> <mailto:jancsika at yahoo.com>> wrote:
>>>> #2 is hard.  Where would you start and how would you proceed?
>>> I think what makes sense is to list out the main interfaces to the 
>>> DSP core that are currently being used by TCL.
>> I think by DSP core you're referring to:
>> * DSP graph stuff
>> * message dispatching system
>> * various widgetbehaviors and data structures parentwidgetbehaviors
>> * all the gui logic in g_editor.c
>> * gui queuing stuff, array selection/manipulation logic, mouse motion 
>> callbacks, and probably other things I'm forgetting
>> Is this correct?
> Yes, minus the widgets and gui queuing stuff, etc. I'm talking about 
> finding a way to separate the strictly gui stuff from the DSP graph. I 
> recognize that some of that is required, so I'm trying to think 
> pragmatically. Obviously you're a better judge of that as you have 
> more experience with the code in the area.
>>> In the simplest case, we could literally create wrapper functions 
>>> which emulate the tcl argument lists. libpd currently wraps the 
>>> formal message sending, midi, & processing areas. I think now we 
>>> need to see if it's possible to wrap the DSP graph 
>>> editing/manipulation, canvas, patch loading/saving, etc.
>> I'm not clear on what libpd actually includes.  For example, does all 
>> the logic from g_editor remain intact?
> Yes. Everything is still there. It merely abstracts sending messages 
> and midi into and out of the libpd instance. I don't see why we 
> couldn't do the same with what's needed by an external gui wrapper 
> around it.

Hm... I didn't realize that.  That being the case, you could certainly 
go ahead and figure out some interim way of sending and parsing tcl 
messages using whichever gui toolkit you prefer. However, it's worth 
understanding a bit about why Pd-l2ork has diverged somewhat from the 
code you'd be wrapping (in no particular order, and definitely not 
* displacing selected objects requires a message from core -> gui for 
every single object that is selected.  Here's such a message for 
displacing [clip] by one pixel:

.x9892638.c move .x9892638.t9896128 1 0
.x9892638.c coords .x9892638.t9896128R 40 37 72 54
.x9892638.c itemconfigure .x9892638.t9896128R -dash ""
.x9892638.c coords .x9892638.t9896128o0 40 53 47 54
.x9892638.c coords .x9892638.t9896128i0 40 37 47 38
.x9892638.c coords .x9892638.t9896128i1 52 37 59 38
.x9892638.c coords .x9892638.t9896128i2 65 37 72 38

Compare to Pd-l2ork for the same action:
.xa261e08.c move selected 1 0

And here's the Pd-l2ork message for displacing 100 selected [clip] 
objects by one pixel:
.xa261e08.c move selected 1 0

(Compare to 36K of messages that Vanilla must send in order to do the 
same thing.)

It's even worse for "Put" menu arrays.  Just fire up Pd with the "-d 3" 
flag and look at
what gets sent from core -> gui every time you move the array one pixel.

* Vanilla only has a single "undo" level.  So if you want the gui with 
libpd to be at all modern you'll have to either a) add undo facilities 
to the core or b) code up a completely separate model of Pd objects in 
whatever language your gui uses.  matju took route "b" in DesireData-- 
if you can still dl it, look in "poe.tcl"-- it's a tcl object-oriented 
library that keeps track of objects/canvases/etc.  (Tcl/Tk 8.6 includes 
an object-oriented library in the core, so maybe this is easier to do 
now.) Ivica took route "a" in Pd-l2ork.  Maybe there's some easier way 
to do this, but if you go a different route make sure it's maintainable.

* Most of the vanilla stuff doesn't even make use of the sys_queuegui 
functionality which (as far as I understand it) can filter out needless 
calls to the gui.

* If you don't want to make changes to the core libpd stuff, the 
problems mentioned above still cause dropouts.  The core is sending (and 
the gui is receiving) enormous amounts of data over a socket while the 
audio engine is trying to meet deadlines.  Additionally, any gui 
functionality you want to add on the gui side will be on top of what's 
already in g_editor.c.  That will create unnecessary complexity.  You'll 
essentially have one set of widget/canvas behaviors that get inspected 
in the core and send calls back to the gui, plus another set of 
widget/canvas behaviors that are defined in the gui and don't send 
messages at all to the core.

That's just off the top of my head.  There are additional questions of 
design-- why the editing algos are even in the core instead of using the 
gui-toolkit which presumably has well-written, well-tested algos to do 
that kind of stuff very fast.  (Plus the gui-toolkit is presumably doing 
that regardless, _every_ time you move the mouse in the window, so its 
wasted effort, especially for large patches with lots of objects on a 
canvas.)  But if you're going to do incremental changes you don't have 
to tackle those right away.


> --------
> Dan Wilcox
> @danomatika
> danomatika.com <http://danomatika.com>
> robotcowboy.com <http://robotcowboy.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140113/57e0ada7/attachment.htm>

More information about the Pd-list mailing list