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.