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@yahoo.com mailto:jancsika@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@yahoo.com mailto:jancsika@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