In Pd-l2ork, I've added [draw] commands to data structures which implement a subset of SVG functionality.  (Essentially its the same functionality most 2d APIs offer-- affine transformations, paths, and grouping.)  I also have the usual mouse events which can be associated with each shape in the drawing.  In fact, I just found out HTML5 has some touch events, so I'm going to test them out with my new RPI touchscreen. :) As far as d3 and friends-- I think the thing to do is just load whatever framework along with webpd (or use that framework in my gui port), then send messages back and forth between the two. In my port I'm just using the DOM fairly directly, but it's pretty easy to leverage any of the various frameworks under the hood to get more efficiency/expressivity in rendering the patch.  The one danger I'd point out is adding features inside Pd proper.  Even the very simple bbox calculation for Pd-Vanilla's scalars can quickly eat up cpu time and interrupt audio.  The complexity it takes to get everything to "just work" from the same programming environment is evident from the number of processes running in a modern browser. -Jonathan

 On Sunday, September 13, 2015 10:49 AM, patrice colet <colet.patrice@free.fr> wrote:

Hello,

Le 13/09/2015 11:44, s p a écrit :

Hi Py,

I think WebPd core could definitely be used for that, and thus the refactoring I am doing these days is a good thing as it will create a good base to start these kind of projects. Personally, I am not very familiar with graphics on the web (especially when it comes to WebGL), but I am sure that for anyone with a good experience in this, it should be pretty straightforward, for example using one of the many good libraries that make WebGL, SVG or canvas easier (d3.js, three.js, ...), to replicate some GEM objects in WebPd. And would be nice indeed! But I see this as something more in the future ...

replicating datastructure might be a good start.

I've found out that gpointers provide a nice environment for storing/interfacing Gem objects parameters, it's fast, easily reliable for hardware storing, or streaming, one inconvenient might be complexity of implementing.

On Tue, Sep 8, 2015 at 10:07 AM, Py Fave pyfave@gmail.com wrote:

hello pdlisters

just dreaming of possibilities as i use sound AND images and can't have the time and will to really learn programming (outside of patching).

as a limited human,

I think we need GEM or sort of ported in the browser. what are the current possibilities?

bridges to things like paper.js and GLSL ( webgl) (shader toy) would make a great envirronnement,

but currently the knowledge necessary is too far away for the rest of us (wich i belong to)

even if there is need for server- side things to implement interaction (with arduino for instance),

this is where pd would be needed.

please tell me what the solutions or directions are now for this.

I am sure many would like this implemented?

sorry for my english.

Thank you

Py

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

-- Sébastien Piquemal

----- @sebpiq  ----- http://github.com/sebpiq  ----- http://funktion.fm

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

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

Same as the tcl/tk GUi-- it communicates over a socket connection with Pd. Early on I was looking at using Qt in a separate thread.  matju actually provided some skeleton code for doing this, but it quickly became clear to me that this would become too complex to maintain or even finish.  I just don't see how to do it right without constraining the API to sending messages back and forth-- and if I'm going to do that I might as well use existing infrastructure. With nwjs I started out trying to separate the GUI-toolkit-specific code (stuff like creating menus, locating the window on the screen, etc.) from the other code.  However, I've realized that it would also be helpful to separate the node.js stuff (finding the pwd, reading from filesystem, etc.) from the pure javascript stuff.  But initially it's been a greater sanity-check to follow the tcl/tk code rather closely just to make sure as many of Pd's idiosyncrasies work in the new GUI. But importantly-- outside of some wrappers in s_inter.c, there is no C code containing strings of code in another language.  It's just typed parameters similar to pd_vmess, plus a set of convenience functions for sending array data.

Btw-- we just got PACDATA up and running, and the animation is smooth with no audio dropouts on my Lenovo X60. -Jonathan

 On Monday, September 14, 2015 12:02 PM, s p <sebpiq@gmail.com> wrote:

Jonathan, I'm curious how is the pd-l2ork GUI implemented?

On Sun, Sep 13, 2015 at 8:40 PM, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:

In Pd-l2ork, I've added [draw] commands to data structures which implement a subset of SVG functionality.  (Essentially its the same functionality most 2d APIs offer-- affine transformations, paths, and grouping.)  I also have the usual mouse events which can be associated with each shape in the drawing.  In fact, I just found out HTML5 has some touch events, so I'm going to test them out with my new RPI touchscreen. :) As far as d3 and friends-- I think the thing to do is just load whatever framework along with webpd (or use that framework in my gui port), then send messages back and forth between the two. In my port I'm just using the DOM fairly directly, but it's pretty easy to leverage any of the various frameworks under the hood to get more efficiency/expressivity in rendering the patch.  The one danger I'd point out is adding features inside Pd proper.  Even the very simple bbox calculation for Pd-Vanilla's scalars can quickly eat up cpu time and interrupt audio.  The complexity it takes to get everything to "just work" from the same programming environment is evident from the number of processes running in a modern browser. -Jonathan

 On Sunday, September 13, 2015 10:49 AM, patrice colet <colet.patrice@free.fr> wrote:

Hello,

Le 13/09/2015 11:44, s p a écrit :

Hi Py,

I think WebPd core could definitely be used for that, and thus the refactoring I am doing these days is a good thing as it will create a good base to start these kind of projects. Personally, I am not very familiar with graphics on the web (especially when it comes to WebGL), but I am sure that for anyone with a good experience in this, it should be pretty straightforward, for example using one of the many good libraries that make WebGL, SVG or canvas easier (d3.js, three.js, ...), to replicate some GEM objects in WebPd. And would be nice indeed! But I see this as something more in the future ...

replicating datastructure might be a good start.

I've found out that gpointers provide a nice environment for storing/interfacing Gem objects parameters, it's fast, easily reliable for hardware storing, or streaming, one inconvenient might be complexity of implementing.

On Tue, Sep 8, 2015 at 10:07 AM, Py Fave pyfave@gmail.com wrote:

hello pdlisters

just dreaming of possibilities as i use sound AND images and can't have the time and will to really learn programming (outside of patching).

as a limited human,

I think we need GEM or sort of ported in the browser. what are the current possibilities?

bridges to things like paper.js and GLSL ( webgl) (shader toy) would make a great envirronnement,

but currently the knowledge necessary is too far away for the rest of us (wich i belong to)

even if there is need for server- side things to implement interaction (with arduino for instance),

this is where pd would be needed.

please tell me what the solutions or directions are now for this.

I am sure many would like this implemented?

sorry for my english.

Thank you

Py

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

-- Sébastien Piquemal

----- @sebpiq  ----- http://github.com/sebpiq  ----- http://funktion.fm

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

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

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

Hi ub,Did you forget a link? I'd love to see a demo patch of it in action.

-Jonathan

 On Monday, September 14, 2015 2:13 PM, "ub@xdv.org" <ub@xdv.org> wrote:

hello pd-list,

ever dreamed of complex, distributed, networked architectures involving pd?

well, this external might help to reduce the boilerplate patching for any such plans a lot. zero-mq [1] is a low-latency, low-level messaging library with a vast family of language bindings and its own ideology of usage patterns to reliably solve common distributed computing problems.

the message-parsing code for the external is cloned from netsend/netreceive so the external is mostly FUDI compliant. mostly, because it doesn't support binary mode.

this is alpha (at best), so it needs testing. let me know how it goes. also if you spot something dodgy in the code. long time no C.

cheers, ub

[1] http://zeromq.org/

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