Open full view…


Fri, 27 Jun 2014 16:22:48 GMT

I'd like to start on a simple visualizer to make debugging easier. At least one that visualizes the code that is send to the SSB's, maybe even a visualizer on steps level. The code that's send to the SSB, we call that set point info? Could we collect some notes here so I can figure out the syntax etc? I think I'll start with an interface where you can drag files on, but in the future we could connect this to a live socket feed from the Tosqa host. Regarding a steps visualizer, how would that work? How would you like to input data into this visualizer? Textfield / file / ... ?

Fri, 27 Jun 2014 18:57:46 GMT

I absolutely *love* browser-based debuggers. The fact that you can just hand-execute any javascript command to control the process in e.g. Chrome Javascript tools, as well as just the ease of making an interface makes it awesome.

Sun, 29 Jun 2014 21:10:37 GMT

How would the messages reach the browser? Would there be a Go gadget that outputs these through socket messages? A gadget that would accept setpoints as input? I would create it using svg, but using D3 feels like overkill to draw a few lines. I used svg.js in other visualizers.

Sun, 29 Jun 2014 22:14:17 GMT

This is where things will get interesting: we're not doing this yet, but gadgets need to become _live_ in the circuit editor, so they can indeed respond to events. The goal will be to make a gadget in the browser look like it *is* the real thing, even though it is (at least partly) running in the host. So a simulator gadget could have say two inputs, X and Y, and respond by drawing the path in real time. There are already real-time streams of database events going to the browser (via `jeebus.attach`), this can hopefully be done similarly. Implementing this will help us solve the very general issue of "coalescing" the user's view of what will internally have to be implemented partly in Go on the server and partly in JavaScript on the client, with as end effect that the viewer won't notice the distinction.

Sun, 29 Jun 2014 22:24:48 GMT

(I've been reading through a lot of the Pure Data docs, a great source of ideas...) W.r.t. the client side: have a look at EventEmitters, which is a standard mechanism in node.js, and with [this implementation]( for the browser, which is already included in Tosqa. One idea would be to "subscribe" to setpoint events in JavaScript, so you can have your code called on each such event (separate ones for each SSB axis), with say a `[ticks, steps]` vector as value (later to be extended further).

Sun, 29 Jun 2014 22:36:28 GMT

I understand, that's why it was thinking of starting with files as input. But if you think we should create a live simulator we can try. I don't understand these event's your talking about. I was thinking of creating a separate little project for now, one which just becomes a socket client. Integrating it into the main circuit editor require much more time, partly because I would have to learn AngularJS. Also it would require some ui design, since it would become a page or panel.

Sun, 29 Jun 2014 22:48:11 GMT

You can add a sense of time to the simulator by reading a sample file, as you suggest, and instead of processing it right away, turning each of the entries into an event, sent gradually over time. IOW, the simulator will need to respond to a callback which "feeds" it new setpoints. In short: use JS's `setInterval` to "emit" events, then write the simulator to subscribe to those events. With such an approach, you can easily switch to events which come from the websocket, later on. I suspect that a lot can be done without immediately having to dive into Angular as well.

Mon, 30 Jun 2014 16:19:16 GMT

[Here]( is an example of a graph in a circuit (patch) in Max/MSP - see the "Improved Audio Engine" section. A simulator for Tosqa could perhaps look like that in the browser, with the option to view it outside the circuit editor as well.

Mon, 30 Jun 2014 16:26:33 GMT

That's very neat! I was worried that something like that might be to small for a preview. But maybe we could implement a maximize kind of trick, where it temporarily fills up most of the screen.

Mon, 30 Jun 2014 18:31:22 GMT

what about adding (java)scripted gadgets to the circuit editor. A gadget with a script[string] feed and a run[bool] feed. The script will be put in the DB and will be executed when run==true

Mon, 30 Jun 2014 18:44:23 GMT

Yes, that's on the map. It'll take some work, though - JS needs to run on the host in Go, and also has to be tied into the Flow mechanism

Mon, 30 Jun 2014 19:01:35 GMT

this (maybe needles to say) will then easily become any simulator we need

Mon, 30 Jun 2014 20:06:42 GMT

Ah, good point. On the host side, JS could indeed act motor simulator, etc - I may have been mixing up simulators and visualisers. Ok, this does raise the priority to get JS going.

Mon, 30 Jun 2014 23:04:22 GMT

I was still wrapping my head around why this couldn't be purely interface/client sided javascript. Ideally you would like the simulator to act as a log as well, where it logs the movements when there isn't a interface (circuit editor) open, this requires something to run on the host. Why should this be JS ran on the host btw? Is making development easier because it skips a compilation step the reason? This isn't essential in this case right? The logic of drawing the actual pixels and maybe even interaction (like a time scrubber) should probably be interface/client sided javascript. I'm not quite sure how we would "package" that though...

Wed, 02 Jul 2014 08:42:40 GMT

Small update, I have a static preview My ToDo:

Sun, 06 Jul 2014 23:23:20 GMT

I think my previewer is starting to get useful. Could we put it behind or something so we can start using it?

Mon, 07 Jul 2014 05:51:13 GMT

Nice work. We can indeed deploy it on a subdomain. Will you be @ VCXL today?

Mon, 07 Jul 2014 06:03:52 GMT


Mon, 07 Jul 2014 08:15:32 GMT

( The repository is moved to: )

Mon, 07 Jul 2014 08:34:48 GMT

It's online at [](

Sun, 13 Jul 2014 15:06:00 GMT

I've re implemented it using D3 and added zoom and pan functionality. David could you pull and update (or give me a way to do so)?