“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.” –John Gall, Systemantics
At Moore’s Cloud, we believe in what is colloquially known as “agile methodologies”. We will be designing software bit by bit, and releasing it as we go. “Simple and works” takes solid precedence over “Complicated and doesn’t exist”. That said, it is not a great idea to head out into the wilderness completely aimless. What follows is a summary software architecture plan. It is a direction and a departure point. It is not written on stone tablets, and I am no moses, but I do have lots of experience and ideas. As we work and play with the light, experience will likely tell us new things that we could not possibly have thought of in advance.
We are defining the software in layers, and then releasing each layer as we complete it. Of course, most of this will not be possible unless we are funded on our Kickstarter campaign, so if you like the sound of this, don’t forget to give that page a visit. And also tell your friends how exciting it will be on the social network of your choice!
The layers are something like this:
[light hardware]
[compositor] < — [low level api] < –[REST api/OSC api/whatever protocol api]
[wuvoxels/sing] [other hardware, accelerometer, etc]
[blocks]
[apps]
At the lowest level is a piece of software we call the compositor. The compositor is a server, and its main duty is talking directly to the light’s LED strips on behalf of all the other software on the system. This is the direct solution to the problem we have seen when two of our demo programs try to run simultaneously; they compete for control of the LEDS and the result is a rapid and annoying flickering. If the apps instead talk to a compositor, then the compositor can manage priority, layering, flicker prevention, and other benefits afforded by central control of the LEDs. Thus the compositor on the light is Half way between something like a playlist manager and a desktop OS compositor.
The compositor will have 6 layers or “slots” total. 4 of these slots are “free” for use, perhaps by assigning an app to each slot. 2 of the slots are reserved for the system; one on top with the highest priority for notifications/alerts/emergencies/instantaneous feedback and one on the bottom with the lowest priority, for the globally set background color. Our hardware may have a “pxp” circuit that can accellerate the operation of the compositor, but I will likely write it in software first to ensure that it can run on most kinds of software and simulators.
The next level up is the wuvoxel/sing framework. You have the option of writing software that talks directly to the compositor by sending it framebuffers, but the wuvoxel/sing framework gives you higher level abstractions to deal with space, volume, color, time, and animation- which is what I like to call “magic” because they are abstractions that permit you to build rich symbolic worlds. Programs written with this layer currently talk directly to hardware but in future will talk to either the compositor server or a desktop ”simulation server”.
On the next level up we have blocks. Blocks are like legos made of code. The idea here is that these are bundles of code, written in (almost) any programming language, with well defined streaming inputs and outputs. Blocks will be very much like Yahoo Pipes, Squeek, Scratch or IFTTT. The way blocks work is inspired by functional programming concepts; dataflow programming in particular. This may sound scary at first, but once you get the hang of it, it’s really easy. Blocks can be “Sources”, “Filters” and “Sinks”, terms borrowed from Electronics engineering! So building an app with blocks will be a bit like building a circuit. But without the danger or complexity.
You may build apps out of blocks. As an example, an “Alarm Clock” app
could be constructed like this:
a SOURCE- time, which is quite simply the number of milliseconds since midnight january 1st 1970.
a FILTER, which transforms the source into a wave which peaks in mornings and evenings and valleys in afternoons and after midnight.
a FILTER, which transforms the wave into a color of varying brightness
a SINK, which simply takes that color and sends it to the compositor.
The blocks are hooked together using either the gui we will build, or directly in the simple JSON based block format. Once an app is constructed this way, the app is sampled at the required (potentially variable) framerate to generate the framebuffers and other hardware events.