[PD] Aciles - the world's worst web server in Pd

Chris McCormick chris at mccormick.cx
Fri Nov 18 16:16:38 CET 2016

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


> 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 

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.




More information about the Pd-list mailing list