On 03/20/2015 04:35 PM, Miller Puckette wrote:

My memory on this isn't altogether reliable, but I believe I put in the extra deletion to fix a situation in which sometimes inlets and outlets on GOPs never got erased when the object was deleted. I wasn't able to figure out at the time how to get everything reliably erased exactly one time, so I gave up and erased it all twice.

I have found the issue of when to draw and when to erase GOP stuff very hard to understand....

Ok, sounds like it's easiest to leave in the extra deletion for now.

One thing that simplifies all that is the svg group. For text objects and iemguis the xlets are children of a parent "gobj" group. The children inherit the translated position of the parent, as well as any scaling factors (which saves many glist_x/ytopixels calls). Also, you only have to create the parent "gobj" group to delete all the children.
(Other modern toolkits like Qt have similar grouping APIs, too.)

I think it's possible to do the same on the level of the gop, and make all the visible xlets and gobjs be children of the parent gop group. I was going to try that with garrays, but miraculously they seem to be working at the moment. So I'm just going to back away slowly... :)

-Jonathan

cheers Miller

On Thu, Mar 19, 2015 at 04:08:40PM -0400, Jonathan Wilkes via Pd-list wrote:

...

Hi list, I'm implementing graph-on-parent drawing in my port of the Pd-l2ork GUI to HTML5.

What I've come across is that both glist_delete and graph_vis will send a message to the GUI to erase the objects shown in the GOP window. So when you select a gop subpatch and click <BackSpace>, Pd sends two "delete" messages to the GUI for each object shown in the GOP window.

Is there an easy way to change this so that only one "delete" message gets sent to the GUI per object? It's easy enough to ignore the extra messages. But it's _way_ easier to maintain and debug when you don't have to track down and analyze two sources of GUI deletions, especially when the dataflow is obscured by function callbacks in C.

-Jonathan

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Hi Chris, I have a forked version of Pd-l2ork on github atm, but it's currently full of stop-gaps and curse words.

The main tasks left are (roughly in order):0) figuring out how to integrate the new gui into the build scripts.  I don't like build scripts, package builds, build dependencies, or autohallofmirrors.

If anyone who doesn't hate all of the above wants to help me with any of the above I'd appreciate it.

The rest are things I'm currently working on...

1. port Ivica's z-ordering algorithm.  I still don't understand how it works, and it might take some time since tk canvas' raise is almost certainly faster than reordering DOM elements (which is the only way to control svg z-ordering).
2. port Ivica's iemgui size/label anchors. These do an end-run around the widgetbehavior callback API, so that might take some time to get right.
3. change the gui-side parser to handle multi-line text.  Currently I'm splitting the incoming socket data on newlines, which lets me separate the new-style calls from the old tcl ones.  That's been invaluable-- it lets me see the exact tcl call for a piece of missing functionality in a running instance of Pd.  This needs to be done when all the old sys_vgui calls are gone-- otherwise I'll either get errors on the gui side from tcl code, or I'll have to add complexity to catch them.

Do you anticipate your HTML5 based UI will be able to work against any

version of Pd (vanilla, pd-extended), or is it Pd-l2ork only? Unfortunately, no.  That's the simple answer, as evidenced by the lack of hooks in libpd for all the functionality inside g_*.c. The patches themselves are 99% compatible with anything else.  (I say 99% because there's a positioning offset to iemguis in Pd-l2ork that I still don't fully understand, but other than that you're golden.) As far as building arbitrary patch UIs in Javascript, I think the way to go would be to get a websocket connection class in Pd Vanilla.  Then you could use that to send FUDI messages between any modern browser and a running instance of Pd.  I'd be careful with that, though.  I don't really understand how websockets are any more secure than the idea of an arbitrary webpage making arbitrary tcp/ip connections.  And I could totally see a patch author forgoing encryption and other sane functionality because they fear it would make things too slow. Finally-- when I get a chance I'm going to add a data structure drawing instruction to display an svg object.  Svg objects can themselves include scripts.  So one could actually write an entire GUI in an svg file-- including event handlers, animation, etc.  In that case the Pd engine only has to create the class and send a message here or there to trigger events, and the GUI process takes care of the heavier logic.  But even as it is, I can get decent performance by using [line] and friends to do basic animation, or even transforms.  The actual rendering happens in the GUI process so as long as you aren't passing around too many messages it can stay out of the way of the audio.

-Jonathan

 On Wednesday, March 25, 2015 9:29 PM, Chris McCormick <chris@mccormick.cx> wrote:

Hi Jonathan,

On 20/03/15 04:08, Jonathan Wilkes via Pd-list wrote:

I'm implementing graph-on-parent drawing in my port of the Pd-l2ork GUI to HTML5.

I caught up with Richie Cyngler in Melbourne last weekend and we were talking about your new work. One thing I am really excited by is the idea of being able to use Javascript to do more traditional procedural computation - building complex tables and data structures to use in Pd based composition using a language that enables this without patching together tens of boxes. That and the obvious benefits of wielding the full power of the browser environment to interface with external servers, display information richly, webgl, etc.

Is what you are working on available in a repository anywhere?

Do you anticipate your HTML5 based UI will be able to work against any version of Pd (vanilla, pd-extended), or is it Pd-l2ork only?

Cheers,

Chris.