pouët.net

Oh hey,

back at the last Outline I sat next to Tolle who was using some weird Excel program to tune his demo, so this got me intrigued and I asked him what that thing is - he explained Rocket a bit to me, and I wished I had something like this for JavaScript. So after finding no similar projects I wrote my own spin off, which uses some middleware to forward Websockets to Rocket Sockets (tihihi) and back. Meaning you can use Exc^WRocket to sync your JavaScript demos.
It comes in two flavours, one to use when you're in sync mode - and the other one for when pants are being dropped - which only counts ~4kb, stripped from all Websocket shenanigans.

Looks like this

Code with two examples at https://github.com/mog/jsRocket

Only known bug so far is, that it spasms out Rocket when moving way too swiftly through the rows, which I think is either a problem in the Python middleware or my Websocket~Stream~Code.

FWIW http://pouet.net/prod.php?which=60815 used jsRocket before it was cool ;)

Alpha C was so kind to hand me a short tune to make an example demo with sound and a spinning cube http://embed.plnkr.co/uQO1MTeCLIoVLYbo0zim (starts right away with loud sound, for you lovely ppl sitting in a quiet office)

cool

nice work.

also, check this: http://marcinignac.com/blog/timeline-js/

Awesome work :)

kusma <3

I wonder, how hard would it be to make the editor speak directly over websockets?

@pandrr: I used Timeline.js as the shader param animator in all of my WebGL demos! Very easy to hack but a bit buggy sometimes.

@kusma: Nothing should prevent that, it's very simple to make a socket connection. Maybe a few nights of hacking I'd say if one uses a convenience library on top of the JS websocket API to make things a bit easier.

Not that hard I think, found some C libs at Wikipedia - and even wanted to fork your Rocket, however my C skills are slim to none :)

A "save as JSON" output would be neat as well, thinking the real realtime guys might appreciate a "save as binary" as well.

Also thanks for that great tool, found reversing the protocol quite amusing with a cold beer in winter :)

Hm, I can't get jsRocket to work; when it connects from the example, it seems the editor requests a zero-length track name, followed with a bunch of track-names that contain only nul-characters... Any clue what I'm doing wrong?

That sounds odd. Using Chrome? Using a bleeding edge Rocket with protocol changes?

Does it work when you use these compiled Websockify/Rocket executables?

I'm using the master-branch from the rocket-repo, without changes. There are ages since there were any protocol changes. I'm using Chrome, yes.

By the way, it seems I was able to write something that performs a somewhat hacky WebSocket handshake, so now I only need to get WebSocket frames working, I guess.

that excel thing looked like a tracker pattern... i thought you had created an excel based tracker

Oh fuck yeah :D

For the trackname, took me a while to find out one has to send the string length as well - which is done here https://github.com/mog/jsRocket/blob/master/src/syncdeviceclient.js#L151 Even tested it with Umlauts O_o

Looked into the uglyness, and finally was able to let the editor run into a breakpoint in the prehandshake code (the "hello synctracker" one), after that it closes the socket. The delivered string from jsRocket looks like garbage in the inspector - so I figure that's what you meant with reading the frames?

For the JSON output, I forgot about the external save menu point, I do handle that signal from Rocket - however it's only a nop so far, which I'll change :)

Indeed it is. I'm currently reading the RFC to get some more confidence, but I suspect I'll have a proof-of-concept up and running shortly.

And now I'm getting some data through :)

<3
Really owe you a beer, or more :)

OK, what's on that branch should now support WebSocket in theory. Some of the theory have been proven to also work in reality, but I'd be surprised if there's no bugs.

OK, I think that's it for now. the proof-of-concept stuff seems to kind-of-work, both for reading and writing. So now someone who are JS-savvy can try getting the pieces to work together. Please let me know of any bugs, though :)

Fixing the JS side right now, might even be able to get completely rid of websockify dependencies :)

Would it ease the complexity of the JS-end if I made sure each command arrived in a separate WebSocket message? I don't think I do that now, some of the commands are split into multiple messages. But it would be really easy to fix, and probably be more in the spirit of WebSocket design...

Currently they arrive as a stream, and I just cut out the chunks - a bit like the old paper stripe printers.
For clarity it'd sure help to get them one by one, and would help to get rid of the uncertainty when the next package arrives.