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 <jancs...@yahoo.com
<mailto:jancs...@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 <jancs...@yahoo.com
<mailto:jancs...@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
exhaustive):
* 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.
-Jonathan
--------
Dan Wilcox
@danomatika
danomatika.com <http://danomatika.com>
robotcowboy.com <http://robotcowboy.com>
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
