apparently when i thought it was running from your server it was running locally, so I downloaded it, read your documentation and just changed it so that the index.html loads the js from its own folder, it's kinda hard to follow but looks like there is less overhead than a websocket server in pd I say looks like, only from what is seen in the pd patch. now how do i get it to speak FUDI? the semicolons are preceded by a slash in your messagebox, not sure if that will work like a semicolon not preceded by a slash. I would imagine that this would be ok to send 2d arrays right? what about sequencing from javascript? javascript isn't good enough even for a 90 bpm sequencer sending note ons and offs monophonically, the play position indicator falls behind then the messages start lagging, this is with setTimeOut() not the nifty new html audio dsp clock, but i reckon you could implement a an edit view piano roll or multiple ones of the step sequencer in the browser and update a storage object in pd just sending messages about when you add or delete a note. then when playing the sequence pd can send a click every bar or something in case the html view gets behind. and another thing - do you have to connect or open the connection everytime you send a message to the server from a web browser? with sockets in JAVA you just open the connection once and it stays alive. at any rate, nice job making the worst webserver in the world, lol re: joe 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

On Thu, Nov 17, 2016 at 6:03 AM, Billy Stiltner billy.stiltner@gmail.com wrote:

so this could replace the JAVA udp tcp socket overhead ? works from here to your server and back. havent tried it locally yet. how did you figure it out?

On Thu, Nov 3, 2016 at 10:03 PM, Chris McCormick chris@mccormick.cx wrote:

...

Hi all,

Aciles is the world's worst web server, implemented in Pd.

Step 1: Download these two patches and open on your local machine:

• https://raw.githubusercontent.com/chr15m/aciles/master/web-s

erver-help.pd

• https://raw.githubusercontent.com/chr15m/aciles/master/web-server.pd

Step 2: Browse to http://aciles.mccormick.cx/

Step 3: Send some messages between Pd and your browser.

Some things you could do with this:

• Send messages from a web-app to Pd patches and visa versa.
• Control a headless Rasberry Pi Pd with a web-app on another machine.
• Control a libpd patch with a web-app on the same devices's browser.

This software is for Joe's nephew.

Cheers,

Chris.

-- http://mccormick.cx/

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list

On 18/11/16 18:19, Billy Stiltner wrote:

apparently when i thought it was running from your server it was running locally, so I downloaded it, read your documentation and just changed it so that the index.html

Awesome!

loads the js from its own folder, it's kinda hard to follow but looks like there is less overhead than a websocket server in pd I say looks like, only from what is seen in the pd patch.

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.

now how do i get it to speak FUDI?

That's the default mode of operation pretty much. You can send arbitrary Pd data back and forth.

the semicolons are preceded by a slash in your messagebox, not sure if that will work like a semicolon not preceded by a slash.

I will have to double check that. Not sure what is going on there.

I would imagine that this would be ok to send 2d arrays right? what about sequencing from javascript?

Arrays might work ok if they're not too huge. Basically if all of the data crosses from the browser to Pd in one hit and then there is a pause while the connection is re-established (it is broken after each send).

For the same reason doing the sequencing from the JS side sounds risky and will probably introduce bad latency.

What I would do instead is use it to build lightweight UIs in HTML/JS and do all the time/dsp critical stuff on the Pd side. You can send tick/position indicator from Pd back to the browser and then it doesn't matter if it looks a little out of sync, as long as it doesn't sound out of sync.

javascript isn't good enough even for a 90 bpm sequencer sending note ons and offs monophonically, the play position indicator falls behind then the messages start lagging, this is with setTimeOut() not the nifty new html audio dsp clock,

You can get things pretty tight doing it the latter way. Check out Chris Wilson's work with in-browser metronomes. The cljs-bach project looks pretty wild as well if you are into LISP. :)

but i reckon you could implement a an edit view piano roll or multiple ones of the step sequencer in the browser and update a storage object in pd just sending messages about when you add or delete a note. then when playing the sequence pd can send a click every bar or something in case the html view gets behind.

That sounds awesome! Anything where you are doing mostly UI stuff in the browser and just sending configuration back to Pd should work ok.

and another thing - do you have to connect or open the connection everytime you send a message to the server from a web browser? with sockets in JAVA you just open the connection once and it stays

alive.

Yep that's exactly how it works. Well actually I think keep-alive is on so the actual socket stays open but the important thing is there is a small delay while the browser prepares another "GET" request and if you try to send data back from Pd to the browser while that GET has not yet initiated then the browser will ignore it.

If netsend were able to do targeting by ip:port source then it would be possible to interleave two connections to make it more robust.

at any rate, nice job making the worst webserver in the world, lol

Thank you, and thank you for your interest!

re: joe 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.

I will try to do more testing with this on mobile devices at the workshop here at PdCon on Saturday.

Thanks Billy.

Cheers,

Chris.

the / and ; aRE being prepended with / so it's a tcl tk thing i guess,

On Fri, Nov 18, 2016 at 9:32 PM, Billy Stiltner billy.stiltner@gmail.com wrote:

re: "Yeah it would be but the sticking point is going to be the small amount of crypto stuff that websockets require. Not impossible mayb" it's all in here,

https://sourceforge.net/projects/websocketserverinapatch/files/

looks like lots of things could be simplified as well as use of the vanilla netrecieve

i don't have tof/toasci or would test it out

one thing i dont undrstand about aciles is why the 2nd netreceive within the server?

Hi Billy,

On 17/11/16 19:03, Billy Stiltner wrote:

so this could replace the JAVA udp tcp socket overhead ?

In theory yes but I haven't done extensive testing yet to determine if it's robust enough. One thing is for sure - if you send messages too quickly in succession they will get dropped. That's basically unavoidable due to the hacks it uses.

works from here to your server and back.

Cool! Thanks for trying it out. As you point out in the other email it actually doesn't contact my server - only the HTML file is loaded from there and then the communication is happening locally.

how did you figure it out?

I guess I just realised that recent features of netsend (bi-directional, binary) allow it to work. Also I was visited by a magical binary elf at midnight who imparted to me the secrets three.

Cheers,

Chris.