[PD-announce] All-in-one 'websocket server + cross-browser multiplayer/multitouch demo' patch for Pd-extended
"websocket-server in a patch.pd" single pd patch file contains a reusable and fully documented websocket server, meant as an easy way to experiment with Pd<->web-browsers communications through websockets, without the need of other software or any external to compile
A demo is included in the same patch : 'Flames', a simple cross-browser, multi-touch and multi-player graphical interface which makes Pd play creepy sounds :) and its javascript code for websockets is also documented.
Just try it : open it with Pd-extended 0.43.4 on Windows, Mac or Linux, fire any recent web-browsers (on same machine or other computer, smartphone or tablet on same local network) with the URL provided in the main window, and you're good to go ! You can download the patch from these forums : http://puredata.hurleur.com/sujet-10062-websocket-server-patch-extended-demo... required to get the file)
direct link to patch : http://puredata.hurleur.com/attachment.php?item=4945
Cheers,
Nicolas Lhommet
Sorry, correct links to forums :
http://puredata.hurleur.com/sujet-10062-websocket-server-patch-extended-demo
http://codelab.fr/4769 (registration required to get the file)
2014/1/18 Nicolas Lhommet nlhommet@gmail.com
"websocket-server in a patch.pd" single pd patch file contains a reusable and fully documented websocket server, meant as an easy way to experiment with Pd<->web-browsers communications through websockets, without the need of other software or any external to compile
A demo is included in the same patch : 'Flames', a simple cross-browser, multi-touch and multi-player graphical interface which makes Pd play creepy sounds :) and its javascript code for websockets is also documented.
Just try it : open it with Pd-extended 0.43.4 on Windows, Mac or Linux, fire any recent web-browsers (on same machine or other computer, smartphone or tablet on same local network) with the URL provided in the main window, and you're good to go ! You can download the patch from these forums :
http://puredata.hurleur.com/sujet-10062-websocket-server-patch-extended-demo... required to get the file)
direct link to patch : http://puredata.hurleur.com/attachment.php?item=4945
Cheers,
Nicolas Lhommet
this is insane lol you have the webpage in pd send the webpage to the browser before the client(in the webpage) is connected to the server. just exactly how does that work? anyways, the tof library and zexy library things , couldnt they now be replaced with vanilla objects like list to/from symbol? not sure where but i had to add an import xexy object to get this to work, thanks, would like to sgtreamline this thing where that only a few sockets could be open something like this could be invaluable for FUDI from browser to pd and back
On Sat, Jan 18, 2014 at 1:47 PM, Nicolas Lhommet nlhommet@gmail.com wrote:
Sorry, correct links to forums :
http://puredata.hurleur.com/sujet-10062-websocket-server- patch-extended-demo
http://codelab.fr/4769 (registration required to get the file)
2014/1/18 Nicolas Lhommet nlhommet@gmail.com
"websocket-server in a patch.pd" single pd patch file contains a reusable and fully documented websocket server, meant as an easy way to experiment with Pd<->web-browsers communications through websockets, without the need of other software or any external to compile
A demo is included in the same patch : 'Flames', a simple cross-browser, multi-touch and multi-player graphical interface which makes Pd play creepy sounds :) and its javascript code for websockets is also documented.
Just try it : open it with Pd-extended 0.43.4 on Windows, Mac or Linux, fire any recent web-browsers (on same machine or other computer, smartphone or tablet on same local network) with the URL provided in the main window, and you're good to go ! You can download the patch from these forums : http://puredata.hurleur.com/sujet-10062-websocket-server- patch-extended-demohttp://codelab.fr/4769 (registration required to get the file)
direct link to patch : http://puredata.hurleur.com/attachment.php?item=4945
Cheers,
Nicolas Lhommet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
the import zexy was added to the flames demo patch, also had to use deken to install the tof library on linux ubuntu studio xenial xerus and of course point the webbrowser to the port the server was connected to instead of the one shown in the yellow canvas instructions its not 9998 but the other one
On Tue, Nov 22, 2016 at 12:29 AM, Billy Stiltner billy.stiltner@gmail.com wrote:
this is insane lol you have the webpage in pd send the webpage to the browser before the client(in the webpage) is connected to the server. just exactly how does that work? anyways, the tof library and zexy library things , couldnt they now be replaced with vanilla objects like list to/from symbol? not sure where but i had to add an import xexy object to get this to work, thanks, would like to sgtreamline this thing where that only a few sockets could be open something like this could be invaluable for FUDI from browser to pd and back
On Sat, Jan 18, 2014 at 1:47 PM, Nicolas Lhommet nlhommet@gmail.com wrote:
Sorry, correct links to forums :
http://puredata.hurleur.com/sujet-10062-websocket-server-pat ch-extended-demo
http://codelab.fr/4769 (registration required to get the file)
2014/1/18 Nicolas Lhommet nlhommet@gmail.com
"websocket-server in a patch.pd" single pd patch file contains a reusable and fully documented websocket server, meant as an easy way to experiment with Pd<->web-browsers communications through websockets, without the need of other software or any external to compile
A demo is included in the same patch : 'Flames', a simple cross-browser, multi-touch and multi-player graphical interface which makes Pd play creepy sounds :) and its javascript code for websockets is also documented.
Just try it : open it with Pd-extended 0.43.4 on Windows, Mac or Linux, fire any recent web-browsers (on same machine or other computer, smartphone or tablet on same local network) with the URL provided in the main window, and you're good to go ! You can download the patch from these forums : http://puredata.hurleur.com/sujet-10062-websocket-server-pat ch-extended-demohttp://codelab.fr/4769 (registration required to get the file)
direct link to patch : http://puredata.hurleur.com/attachment.php?item=4945
Cheers,
Nicolas Lhommet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/lis tinfo/pd-list
zexy/tabdump is not getting the 0th table element
On Tue, Nov 22, 2016 at 12:48 AM, Billy Stiltner billy.stiltner@gmail.com wrote:
the import zexy was added to the flames demo patch, also had to use deken to install the tof library on linux ubuntu studio xenial xerus and of course point the webbrowser to the port the server was connected to instead of the one shown in the yellow canvas instructions its not 9998 but the other one
On Tue, Nov 22, 2016 at 12:29 AM, Billy Stiltner <billy.stiltner@gmail.com
wrote:
this is insane lol you have the webpage in pd send the webpage to the browser before the client(in the webpage) is connected to the server. just exactly how does that work? anyways, the tof library and zexy library things , couldnt they now be replaced with vanilla objects like list to/from symbol? not sure where but i had to add an import xexy object to get this to work, thanks, would like to sgtreamline this thing where that only a few sockets could be open something like this could be invaluable for FUDI from browser to pd and back
On Sat, Jan 18, 2014 at 1:47 PM, Nicolas Lhommet nlhommet@gmail.com wrote:
Sorry, correct links to forums :
http://puredata.hurleur.com/sujet-10062-websocket-server-pat ch-extended-demo
http://codelab.fr/4769 (registration required to get the file)
2014/1/18 Nicolas Lhommet nlhommet@gmail.com
"websocket-server in a patch.pd" single pd patch file contains a reusable and fully documented websocket server, meant as an easy way to experiment with Pd<->web-browsers communications through websockets, without the need of other software or any external to compile
A demo is included in the same patch : 'Flames', a simple cross-browser, multi-touch and multi-player graphical interface which makes Pd play creepy sounds :) and its javascript code for websockets is also documented.
Just try it : open it with Pd-extended 0.43.4 on Windows, Mac or Linux, fire any recent web-browsers (on same machine or other computer, smartphone or tablet on same local network) with the URL provided in the main window, and you're good to go ! You can download the patch from these forums : http://puredata.hurleur.com/sujet-10062-websocket-server-pat ch-extended-demohttp://codelab.fr/4769 (registration required to get the file)
direct link to patch : http://puredata.hurleur.com/attachment.php?item=4945
Cheers,
Nicolas Lhommet
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/lis tinfo/pd-list
Hi pd folks ! Billy Stiltner kindly forwarded me its recent posts, so I briefly suscribe to the list again only to reply to these questions regarding my old (and sole) publicly released pd tool.
On Thu, Nov 18, 2016 at 16:16 PM, Chris McCormick <chris at mccormick.cx> wrote:
The reason I didn't implement a websocket server is because I'd have to figure out how to do sha hashing in pure-Pd and that is more effort than I can put in right now.
...
did you see the pd websocket server? it has some similar parts but looks way more complicated and is not vanilla plus it uses iemnet tcp server or the onefrom mr peach, would be nice to reduce the number of connections and vanilarize it just for a simple fudi thing
Yeah it would be but the sticking point is going to be the small amount of crypto stuff that websockets require. Not impossible maybe but
difficult.
Yeah Chris, this mostly RFC-compliant websocket-server patch (that I outrageously announced on this list in january 2014) has all the required crypto stuff you talk about (made stricly of vanilla objects) : SHA-1 hashing + Base64 encoding... and how could it be otherwise ?! Billy brought its existence to your attention, so why keep using this conditional tense ? (or is this matter only up to you, New-York New-York?? haha). Since its release, many people found it on Sourceforge after typing "pd websocket" on google and the like, and used the original patch without problem (only recently asking for help with deken). So not impossible maybe but difficult to understand you didn't try to check this stuff...
And to answer to Bill now : except the mandatory [tcpserver] external, the core server subpatch is full vanilla (including crypto), as clearly mentioned next to it in the patch. Only the demo and specific examples used a couple of additionnal externals, mostly for pd messages<->ascii codes conversion (at that time the 'fromsymbol' options of the [list] object were new in vanilla but not yet in latest Pd-extended, which was the target release).
Sure, it's far from perfect, some part could be better, it's heavyweight, cpu intensive, and totally over the top if you just need to send and receive a dozen of little text messages every second. But, even if it won't scale well as message length and the number of clients grows, it has been thoroughly constructed and tested to handle the best as it can multiple concurrent connections/disconnections from all flavors of browsers, and to sustain up to 24 clients (a limit of implementation that can be easily enhanced, or even removed with mrpeach) and hundreds of kilobytes/seconds of total throughput with iemnet external (though lag, freeze or disconnections will occur more frequently when pushing it to the limits).
On Tue, Nov 22, 2016 at 12:29 AM, Billy Stiltner <billy.stiltner at gmail.com> wrote:
this is insane lol you have the webpage in pd send the webpage to the browser before the client(in the webpage) is connected to the server. just exactly how does that work?
This is insanely working like it should do : https://en.wikipedia.org/wiki/ WebSocket#Protocol_handshake
and of course point the webbrowser to the port the server was connected to instead of the one shown in the yellow canvas instructions its not 9998 but the other one
Hum..? There is one and only one tcp port in use (see previous answer)
anyways, the tof library and zexy library things , couldnt they now be replaced with vanilla objects like list to/from symbol?
Yes they can, and to make things easier, I made just that with the new quasi-vanilla version (needs only to add mrpeach via the Help->Find externals menu) now available at the same place : https://sourceforge.net/projects/websocketserverinapatch/
It seems you were looking not only for "incoming text as pd messages" conversion, but also with "semicolon-style-send" support (which couldn't work with the funny but ugly trick of netsend/netreceive used locally only to parse numbers in symbols as proper floats, like the world's worst web server with a fancy name does : so much for your other questions left unanswered..). Maybe you were too shy to ask in your hearty emails, anyway I've added just that in the vanilla "text2pdmessage" subpatch especially for you.
looks like lots of things could be simplified as well as
Some of it could be simplified by dropping extended features like transparent support for both iemnet and mrpeach [tcpserver] externals and the convoluted workarounds addressed to some of their respective bugs in Pd-Extended, like those occuring when stressed or with keeped-alive connections (by the way, this was explained in detail in the info subpatches and comments).
use of the vanilla netrecieve
It can be done with some trivial additions to x_net.c that would bring the missing 'per-socket' operations to [netreceive] with a couple of additional commands + an optional third outlet, similarly to the 'net' externals. I made and tried a 40 lines diff-patch (that doesn't disrupt normal behaviour) and preliminary tests showed good performance and stability with this network intensive patch.
Still, besides simple bi-directionnal http mechanisms now possible for a couple of years in pd-vanilla, a better and more pragmatic approach for websockets, like for any kind of (widespread enough) intensive low level stuff, would be to quickly build an external on top of an existing, well tested library, and that's what Rafael Vega did and announced here in 2013 : https://github.com/dancing-bone-machine/dancing-bone-machine /tree/master/library/dancing-bone-machine/pd/externals/src/websocket_server
"I want to be a part of it... and find I'm A number one, King of the hill, Top of the List..Head of the heap" ahaha!! Tschüß !
Sorry for intruding the discussion ... there's also this solution I've been implementing and using with Pd for live performances :
https://github.com/sebpiq/rhizome
It's node.js based, so it should be very performant.
------ end of advertisment :) ------
On Mon, Nov 28, 2016 at 4:04 AM Nicolas Lhommet nlhommet@gmail.com wrote:
Hi pd folks ! Billy Stiltner kindly forwarded me its recent posts, so I briefly suscribe to the list again only to reply to these questions regarding my old (and sole) publicly released pd tool.
On Thu, Nov 18, 2016 at 16:16 PM, Chris McCormick <chris at mccormick.cx> wrote:
The reason I didn't implement a websocket server is because I'd have to figure out how to do sha hashing in pure-Pd and that is more effort than I can put in right now.
...
did you see the pd websocket server? it has some similar parts but looks way more complicated and is not vanilla plus it uses iemnet tcp server or the onefrom mr peach, would
be
nice to reduce the number of connections and vanilarize it just for a simple fudi thing
Yeah it would be but the sticking point is going to be the small amount of crypto stuff that websockets require. Not impossible maybe but
difficult.
Yeah Chris, this mostly RFC-compliant websocket-server patch (that I outrageously announced on this list in january 2014) has all the required crypto stuff you talk about (made stricly of vanilla objects) : SHA-1 hashing + Base64 encoding... and how could it be otherwise ?! Billy brought its existence to your attention, so why keep using this conditional tense ? (or is this matter only up to you, New-York New-York?? haha). Since its release, many people found it on Sourceforge after typing "pd websocket" on google and the like, and used the original patch without problem (only recently asking for help with deken). So not impossible maybe but difficult to understand you didn't try to check this stuff...
And to answer to Bill now : except the mandatory [tcpserver] external, the core server subpatch is full vanilla (including crypto), as clearly mentioned next to it in the patch. Only the demo and specific examples used a couple of additionnal externals, mostly for pd messages<->ascii codes conversion (at that time the 'fromsymbol' options of the [list] object were new in vanilla but not yet in latest Pd-extended, which was the target release).
Sure, it's far from perfect, some part could be better, it's heavyweight, cpu intensive, and totally over the top if you just need to send and receive a dozen of little text messages every second. But, even if it won't scale well as message length and the number of clients grows, it has been thoroughly constructed and tested to handle the best as it can multiple concurrent connections/disconnections from all flavors of browsers, and to sustain up to 24 clients (a limit of implementation that can be easily enhanced, or even removed with mrpeach) and hundreds of kilobytes/seconds of total throughput with iemnet external (though lag, freeze or disconnections will occur more frequently when pushing it to the limits).
On Tue, Nov 22, 2016 at 12:29 AM, Billy Stiltner <billy.stiltner at gmail.com> wrote:
this is insane lol you have the webpage in pd send the webpage to the browser before the client(in the webpage) is connected to the server. just exactly how does that work?
This is insanely working like it should do : https://en.wikipedia .org/wiki/WebSocket#Protocol_handshake
and of course point the webbrowser to the port the server was connected
to
instead of the one shown in the yellow canvas instructions its not 9998 but the other one
Hum..? There is one and only one tcp port in use (see previous answer)
anyways, the tof library and zexy library things , couldnt they now be replaced with vanilla objects like list to/from symbol?
Yes they can, and to make things easier, I made just that with the new quasi-vanilla version (needs only to add mrpeach via the Help->Find externals menu) now available at the same place : https://sourceforge.net/projects/websocketserverinapatch/
It seems you were looking not only for "incoming text as pd messages" conversion, but also with "semicolon-style-send" support (which couldn't work with the funny but ugly trick of netsend/netreceive used locally only to parse numbers in symbols as proper floats, like the world's worst web server with a fancy name does : so much for your other questions left unanswered..). Maybe you were too shy to ask in your hearty emails, anyway I've added just that in the vanilla "text2pdmessage" subpatch especially for you.
looks like lots of things could be simplified as well as
Some of it could be simplified by dropping extended features like transparent support for both iemnet and mrpeach [tcpserver] externals and the convoluted workarounds addressed to some of their respective bugs in Pd-Extended, like those occuring when stressed or with keeped-alive connections (by the way, this was explained in detail in the info subpatches and comments).
use of the vanilla netrecieve
It can be done with some trivial additions to x_net.c that would bring the missing 'per-socket' operations to [netreceive] with a couple of additional commands + an optional third outlet, similarly to the 'net' externals. I made and tried a 40 lines diff-patch (that doesn't disrupt normal behaviour) and preliminary tests showed good performance and stability with this network intensive patch.
Still, besides simple bi-directionnal http mechanisms now possible for a couple of years in pd-vanilla, a better and more pragmatic approach for websockets, like for any kind of (widespread enough) intensive low level stuff, would be to quickly build an external on top of an existing, well tested library, and that's what Rafael Vega did and announced here in 2013 : https://github .com/dancing-bone-machine/dancing-bone-machine/tree/master/library/dancing-bone-machine/pd/externals/ src/websocket_server
"I want to be a part of it... and find I'm A number one, King of the hill, Top of the List..Head of the heap" ahaha!! Tschüß ! _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
has all the required crypto stuff you talk about (made stricly of
vanilla objects)
whoa... i didn't realize this could all be done via vanilla and when i checked your code this past summer did not see this portion so thanks for pointing it out!
in the end i ended up using python to do crypto stuff but seeing this makes me wonder what more can be done direct in pd. would it be nice to have some kind of "crypto" lib? maybe some of this code could be separated out into abstractions? how to do sha-256, hmac, etc?
i am thinking out loud here...
thanks! m
On Mon, Nov 28, 2016 at 2:47 AM, s p sebpiq@gmail.com wrote:
Sorry for intruding the discussion ... there's also this solution I've been implementing and using with Pd for live performances :
https://github.com/sebpiq/rhizome
It's node.js based, so it should be very performant.
------ end of advertisment :) ------
On Mon, Nov 28, 2016 at 4:04 AM Nicolas Lhommet nlhommet@gmail.com wrote:
Hi pd folks ! Billy Stiltner kindly forwarded me its recent posts, so I briefly suscribe to the list again only to reply to these questions regarding my old (and sole) publicly released pd tool.
On Thu, Nov 18, 2016 at 16:16 PM, Chris McCormick <chris at mccormick.cx> wrote:
The reason I didn't implement a websocket server is because I'd have
to
figure out how to do sha hashing in pure-Pd and that is more effort than I can put in right now.
...
did you see the pd websocket server? it has some similar parts but looks way more complicated and is not vanilla plus it uses iemnet tcp server or the onefrom mr peach, would
be
nice to reduce the number of connections and vanilarize it just for a
simple
fudi thing
Yeah it would be but the sticking point is going to be the small amount of crypto stuff that websockets require. Not impossible maybe but
difficult.
Yeah Chris, this mostly RFC-compliant websocket-server patch (that I outrageously announced on this list in january 2014) has all the required crypto stuff you talk about (made stricly of vanilla objects) : SHA-1 hashing + Base64 encoding... and how could it be otherwise ?! Billy brought its existence to your attention, so why keep using this conditional tense ? (or is this matter only up to you, New-York New-York?? haha). Since its release, many people found it on Sourceforge after typing "pd websocket" on google and the like, and used the original patch without problem (only recently asking for help with deken). So not impossible maybe but difficult to understand you didn't try to check this stuff...
And to answer to Bill now : except the mandatory [tcpserver] external, the core server subpatch is full vanilla (including crypto), as clearly mentioned next to it in the patch. Only the demo and specific examples used a couple of additionnal externals, mostly for pd messages<->ascii codes conversion (at that time the 'fromsymbol' options of the [list] object were new in vanilla but not yet in latest Pd-extended, which was the target release).
Sure, it's far from perfect, some part could be better, it's heavyweight, cpu intensive, and totally over the top if you just need to send and receive a dozen of little text messages every second. But, even if it won't scale well as message length and the number of clients grows, it has been thoroughly constructed and tested to handle the best as it can multiple concurrent connections/disconnections from all flavors of browsers, and to sustain up to 24 clients (a limit of implementation that can be easily enhanced, or even removed with mrpeach) and hundreds of kilobytes/seconds of total throughput with iemnet external (though lag, freeze or disconnections will occur more frequently when pushing it to the limits).
On Tue, Nov 22, 2016 at 12:29 AM, Billy Stiltner <billy.stiltner at gmail.com> wrote:
this is insane lol you have the webpage in pd send the webpage to the browser before the client(in the webpage) is connected to the server. just exactly how does that work?
This is insanely working like it should do : https://en.wikipedia .org/wiki/WebSocket#Protocol_handshake
and of course point the webbrowser to the port the server was
connected to
instead of the one shown in the yellow canvas instructions its not 9998 but the other one
Hum..? There is one and only one tcp port in use (see previous answer)
anyways, the tof library and zexy library things , couldnt they now be replaced with vanilla objects like list to/from symbol?
Yes they can, and to make things easier, I made just that with the new quasi-vanilla version (needs only to add mrpeach via the Help->Find externals menu) now available at the same place : https://sourceforge.net/projects/websocketserverinapatch/
It seems you were looking not only for "incoming text as pd messages" conversion, but also with "semicolon-style-send" support (which couldn't work with the funny but ugly trick of netsend/netreceive used locally only to parse numbers in symbols as proper floats, like the world's worst web server with a fancy name does : so much for your other questions left unanswered..). Maybe you were too shy to ask in your hearty emails, anyway I've added just that in the vanilla "text2pdmessage" subpatch especially for you.
looks like lots of things could be simplified as well as
Some of it could be simplified by dropping extended features like transparent support for both iemnet and mrpeach [tcpserver] externals and the convoluted workarounds addressed to some of their respective bugs in Pd-Extended, like those occuring when stressed or with keeped-alive connections (by the way, this was explained in detail in the info subpatches and comments).
use of the vanilla netrecieve
It can be done with some trivial additions to x_net.c that would bring the missing 'per-socket' operations to [netreceive] with a couple of additional commands + an optional third outlet, similarly to the 'net' externals. I made and tried a 40 lines diff-patch (that doesn't disrupt normal behaviour) and preliminary tests showed good performance and stability with this network intensive patch.
Still, besides simple bi-directionnal http mechanisms now possible for a couple of years in pd-vanilla, a better and more pragmatic approach for websockets, like for any kind of (widespread enough) intensive low level stuff, would be to quickly build an external on top of an existing, well tested library, and that's what Rafael Vega did and announced here in 2013 : https://github.com/dancing-bone-machine/dancing-bone- machine/tree/master/library/dancing-bone-machine/pd/externals/src/ websocket_server
"I want to be a part of it... and find I'm A number one, King of the hill, Top of the List..Head of the heap" ahaha!! Tschüß ! _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
-
Billy Stiltner -
me.grimm -
Nicolas Lhommet -
s p