<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/13/2014 03:11 PM, Dan Wilcox
wrote:<br>
</div>
<blockquote
cite="mid:739E6E58-D9F4-4D3A-9A39-CF54E1E17FF8@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>Woops, forgot the reply-all.</div>
<div><br>
</div>
<div>On Jan 13, 2014, at 2:25 PM, Jonathan Wilkes <<a
moz-do-not-send="true" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/13/2014 09:32 AM, Dan
Wilcox wrote:<br>
</div>
<blockquote
cite="mid:5AD9B4E2-F305-46CD-BB6E-D40A3B3C9BE0@gmail.com"
type="cite">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.</blockquote>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>I wasn't referring to anything in particular, only in
general.</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote
cite="mid:739E6E58-D9F4-4D3A-9A39-CF54E1E17FF8@gmail.com"
type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:5AD9B4E2-F305-46CD-BB6E-D40A3B3C9BE0@gmail.com"
type="cite"><br>
<div>
<div>On Jan 13, 2014, at 1:54 AM, Jonathan Wilkes <<a
moz-do-not-send="true"
href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span style="background-color:
rgb(255, 255, 255);">#2 is hard. Where would you
start and how would you proceed?</span></blockquote>
</div>
<div><br>
</div>
<div>I think what makes sense is to list out the main
interfaces to the DSP core that are currently being used
by TCL.</div>
</blockquote>
<br>
I think by DSP core you're referring to:<br>
* DSP graph stuff<br>
* message dispatching system<br>
* various widgetbehaviors and data structures
parentwidgetbehaviors<br>
* all the gui logic in g_editor.c<br>
* gui queuing stuff, array selection/manipulation logic,
mouse motion callbacks, and probably other things I'm
forgetting<br>
<br>
Is this correct?</div>
</blockquote>
<div><br>
</div>
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.<br>
<br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:5AD9B4E2-F305-46CD-BB6E-D40A3B3C9BE0@gmail.com"
type="cite">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.</blockquote>
<br>
I'm not clear on what libpd actually includes. For example,
does all the logic from g_editor remain intact?<br>
</div>
</blockquote>
<br>
</div>
<div>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.</div>
</blockquote>
<br>
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):<br>
* 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:<br>
<br>
.x9892638.c move .x9892638.t9896128 1 0<br>
.x9892638.c coords .x9892638.t9896128R 40 37 72 54<br>
.x9892638.c itemconfigure .x9892638.t9896128R -dash ""<br>
.x9892638.c coords .x9892638.t9896128o0 40 53 47 54<br>
.x9892638.c coords .x9892638.t9896128i0 40 37 47 38<br>
.x9892638.c coords .x9892638.t9896128i1 52 37 59 38<br>
.x9892638.c coords .x9892638.t9896128i2 65 37 72 38<br>
<br>
Compare to Pd-l2ork for the same action:<br>
.xa261e08.c move selected 1 0<br>
<br>
And here's the Pd-l2ork message for displacing 100 selected [clip]
objects by one pixel:<br>
.xa261e08.c move selected 1 0<br>
<br>
(Compare to 36K of messages that Vanilla must send in order to do
the same thing.)<br>
<br>
It's even worse for "Put" menu arrays. Just fire up Pd with the "-d
3" flag and look at<br>
what gets sent from core -> gui every time you move the array one
pixel.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
* 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.<br>
<br>
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.<br>
<br>
-Jonathan<br>
<br>
<blockquote
cite="mid:739E6E58-D9F4-4D3A-9A39-CF54E1E17FF8@gmail.com"
type="cite"><br>
<div>
<span class="Apple-style-span" style="border-collapse: separate;
border-spacing: 0px;">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; "><span
class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Helvetica; font-style:
normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px; border-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space; ">
<div>--------</div>
<div>Dan Wilcox</div>
<div>@danomatika</div>
<div><a moz-do-not-send="true"
href="http://danomatika.com">danomatika.com</a></div>
<div><a moz-do-not-send="true"
href="http://robotcowboy.com">robotcowboy.com</a></div>
<div><br>
</div>
</div>
</span><br class="Apple-interchange-newline">
</div>
</span><br class="Apple-interchange-newline">
<br class="Apple-interchange-newline">
</div>
<br>
</blockquote>
<br>
</body>
</html>