ED BENNETT: I'm Ed Bennett, and I'm the research specialist in the Art and Technology Department, and we're going to look at the context and tools that we used to develop the ArtBus project and explain like why it's here and what it does.

ArtBus really started out as a protocol, and it started out as a way to wire things together so that everything always wires together the same way with the same pin out and the same connection and then is controlled/addressed the same way.

The way that Max works -- the way that Max's serial works is that it reads and writes from its serial port whenever it pleases, and that causes it to not be able to get along with a lot of serial devices, so that's why it's the hardest place to start to build a serial devices because it's design philosophy it's schedule are just -- does not get along with serial devices that have their own internal sense of timing. Max wants to do its own internal sense of timing which is good thing. So, we wound up having to write a piece of software which referred to as a transmogrifier; it changes the form of one thing into a higher and better form, and what it does is it's a piece of communication software bridge that allows Max to speak to the ArtBus. So, what it does is, in a bidirectional way, it filter data going into the ArtBus and then it reformats data coming back to the ArtBus to make it transparent to the Max user that these things are a little different from each other. However, the entire protocol is based in printable text, so on the Max side and on the ArtBus side you can sniff the traffic and you can see how well you're doing. You can send commands. You can type commands into a terminal. You can display commands. You can display commands going in to and out of the ArtBus as it's running in a text terminal, so you can troubleshoot, you can intervene, you can hack the thing. So, even though you don't program the nodes, you can hack what's going on, so it gives you a great deal of freedom that way.

There are a number of protocols for doing this type thing between multimedia systems. There are systems for the Arduino that do this type thing but some of them are binary, and so you have a binary code that goes by their titer in terms of the number of bytes that they use, bu the number of bytes that are sent between an I/O device, a serial I/O device, and Max for instance, the bottleneck is not in the number of bytes. The bottleneck is in the USB to serial conversion, so the fact that there is a little bit more overhead in sending th text, that's not where the latency would come from. So, on a technical level and specifically, it's in the USB to serial conversion. It's a device that most people use from a company called FTDI that converts -- it's basically a microprocessor tha has a USB side and it has a low-level serial output side; that's what most people use. That's what the Arduino uses.

As far as latency goes, you can do tricks with the FTDI to get it to go faster, but the thing that's most well understood, robust, and reliable is just treating the USB port as a serial port. So, that's what we're doing here. It's all very well understood technology. There's nothing about out it that people wouldn't understand that work in this area.