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...
- 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).
- 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.
- 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.