Project.txt

A listing of functional pieces and who's claiming responsibility:

General Infrastructure:
- Initialization scripts (led pi(s), sound pi(s), master pi)
- Networking setup (static ipaddresses, or discovery with zeroconf?)
- Disk images

Fire:
- (CSW) Flame driver (low level, speaks ! protocol on the RS485 to the flame control boxes)
- (CSW) Flame control (high level, takes REST requests, may hand off to flame driver, may
(in some instances, such as when managing stored sequences) handle independently
of flame driver)
- Interface with fuel depot button box. What does the communication here
look like? (The fuel depot button box - unlike the buttons in the field - communicates
with the flame controller to send its signals) (CSW - suggest we use three ESP8266's, one for
each of the fireflies. The wiring is going to be sort of hell, but <eh>)
- Fuel depot button box - physical construction/design (CSW - Suggest we use the large spare
Pelican case in the 20' container. We could use the laser cutter to make a plastic cut 
out to go in the center)

Sound:
- Sonic pi/Supercollider headless mode. How do we set this up, how do we talk to it
  (Sonic pi sort of assumes a UI - which we don't want. But the lower level 
   Sonic server doesn't need a UI, nor does Supercollider, which is the low level 
   sound driver. How to put these pieces together? What's the API for talking
   to them?) (CSW - As I'm failing to find an easy way to do Sonic Pi headless, I'm thinking
more and more fondly of the low-level C interface I wrote to Alsa for Pulse...)
- Sound interface to REST
- Management of stored sound samples
- Playing of sound samples, control of state. (Note that we want to take advantage of the two
(R/L) channels by treating them completely separately, ie, all effect sounds are mon-aural and
can be played on either of the channels.
- Subwoofer sounds.
- Subwoofer sound management. We don't need sonic pi here - could just play a loop. 
- Gathering of sound assets

Lighting:
- Design general lighting infrastructure. (We have fade candies, and we've previously worked
with OPC and mapped from 3d space to led space (see Pulse or Soma). Is this what we want
to do this time?
- Design lighting communication - How do we specify a particular pattern, or color?
- Lighting interface to REST
- Management of stored lighting assets (?images? palettes? None of the above? See Soma)
- Low level lighting control. Actually talking to the fade candies...

Lil' Bugs:
- (CSW) Wifi robustness. Make sure we don't lose the DHCP lease, that kind of thing.
- (CSW) Command interface design - what are the UDP packets that tell the little fireflies to
do somethimg?
- (CSW) Command interface implementation - on the main pi
- (CSW) Command interface implmentation - on the bugs themselves.
- (CSW) REST interface on main pi

User Interface (Administration Application for All The Things):
- Design - Charlie and Char
- Webserver and UI - Charlie