LightSync Software Design

LightSync Playback System

The LightSync playback system has two primary components:

• Front End: Dispatcher - This software runs on the front end computer (see the Hardware section for elaboration), generally as a plugin to a music player. The software we wrote runs as a plugin in the open source Rhythmbox music library software, though it would be straightforward for a programmer with experience writing plugins to create a version to run in a different music player. This software is responsible for loading the light tracks associated with a song, assigning channels in the saved tracks to physical channels (for instance, the eight channels exposed by the back end lighting control computer in our project), then sending the complete current status of an output device (the back end lighting control computer's parallel port) over the network to that device.
• Back End: Channel Server - This is server software that runs on the back end lighting control computer. In our particular setup, we wrote an eight-channel version of this that outputs to the parallel port, but there is nothing in the design that requires that all output would have to be to a parallel port. For instance, one could write a different channel server that accepts either several binary values or an integer that stand for a color, then display a full screen of that color (essentially using a computer monitor as a light).

Dispatcher Details

The dispatcher software is written in Python, an "very high-level", interpreted, loosely-typed, object oriented language. This allows for rapid development and reliability, since low-level details of the computer are handled by the language automatically. The network transport chosen is UDP, a "connectionless" Internet Protocol commonly used for streaming video and online games, for several reasons:

• The lack of both connection-establishment and delivery-order requirements means that UDP has much lower latency, that is, delay between sending and receiving a message. TCP, the connection-based counterpart of UDP used in HTTP (web) and SMTP (email), guarantees that messages will arrive and arrive in order by requesting re-sends of dropped packets and delaying "later" packets that arrive early until their predecessors arrive. This means that our signals may not arrive in order and one might be dropped once in a while, but as will be explained, this is an acceptable tradeoff.
• Over time, normal connection problems with TCP would mean that the light signals would gradually "drift" and slow down so that the synchronization is lost. This is because if a packet is lost, it will be re-sent, and right ordering is also required, so any anomaly in the connection would cause a delay which would build up. UDP is better for time sensitive transmissions like our light signals, as long as you cope with the lack of a delivery guarantee in your software.
• Delivery guarantees are not required if we transmit the entire status (as opposed to just the changed bit) in each message to a back end: then, if a packet is lost, the lights will simply "catch up" with the next light change. Since light changes will be relatively close together for most cases, and likely only the creator of a manually-designed light track would be able to tell if a light change was postponed, this slight inaccuracy is an acceptable tradeoff to prevent synchronization drift.

Furthermore, the dispatcher is capable of recognizing more than one back end. The above example of using a computer screen as a light output is just one of the many possibilities. Future enhancement of the software may include auto-discovery of available light devices on the local network, so that no programming code would need to be touched to add or remove a back end from the set of light channels addressable by the dispatcher. This would be really, really slick.

Channel Server Details

The channel server software is also written in Python, though it can interface with other languages to perform the actual output. In our setup with a parallel port output, a very brief program (from epanorama) in C that outputs a single byte to the parallel port is called every time a message is received, to properly update the status of the circuits.