Colin Sullivan

Transdimensional Audio Workstation

The Transdimensional Audio Workstation is an interactive musical experience. The machine allows one to tune into another dimension in order to send a musical communication to one’s self. After sending the music, any transdimensional response will be interpreted and played back automatically.

Rotating the knobs creates music and tunes into the alternate dimension. When finished, pressing the button transmits the music that was created to one's other self. Once this is complete, music created by one's other self will be played back.

TAW from a distance.

TAW from a distance.

Interaction

Upon approaching the Transdimensional Audio Workstation, there is a sign which reads the following instructions:

This machine allows for communication with one’s self using transdimensional music

1. Rotate knobs to adjust communication protocol.

Finding your other self may require deep listening.

2. Press button to send transmission with current parameters.

3. The response (if any) will be played back automatically.
Instructions sign

Instructions sign

Transdimensional Audio Workstation demonstration (response removed for privacy reasons)

Inspiration

I have been inspired by many experiences, relationships, works of art, teachings.

See the Karmic Teller Machine: Metafiscal Services in the Middle of Nowhere

This piece is intended to be interacted with in an environment where people are open to new experiences.

Hardware

WS2812 LED rings

WS2812 LED rings

Rotary encoder, using snapped protoboard as a base

Rotary encoder, using snapped protoboard as a base

Rotary encoder wired up!

Rotary encoder wired up!

Three knobs and one button

Three knobs and one button

Building a box

Building a box

Building a box

Building a box

The TAW is composed of:

  • 1 Raspberry PI
    • 1 USB Soundcard
  • 1 Arduino Mega
  • 1 Fadecandy
Inside the Transdimensional Audio Workstation

Inside the Transdimensional Audio Workstation

Software

The TAW software stack is composed of:

  • SuperCollider
    • synths and control logic
    • audio output
  • Node.JS process
    • Input from Arduino
    • Output to Fadecandy
    • Redux state store

This all fits together roughly as shown below:

TAW Architecture

TAW Architecture

State Management

For this project I largely follow the Flux design pattern, in particular the Redux.js implementation. In short, the philosophy works as follows:

  • state is saved in a single entity
  • components are as stateless as possible
  • components manipulate state by "dispatching actions" to the store, which then "reduces" them into actual state changes
    • this results in all state changes happening in a single place in the code

Check out the concepts in the Flux docs and the basic examples in the Redux.js docs to get a feel for how this works.

Perhaps the most technically interesting part of TAW is the "synchronization" of two Redux-style state stores, one in Node.js and another in SuperCollider. This is accomplished roughly by making SuperCollider a "slave" state store of the Node.js store, defined as:

  • When Node.js State Store (JS SS) changes state, forward new state to SuperCollider State Store (SC SS), SC SS conforms to new state as soon as message is received.
  • When SC wants to change state, it dispatches an action by forwarding the dispatch message to the JS SS. This action is reduced in the JS SS just like any other.
How state flows between JavaScript and SuperCollider state stores

How state flows between JavaScript and SuperCollider state stores

As seen above, the state change process is the same regardless of where the action is dispatched from. The advantage of this is, reducers are only written once in JavaScript and the SuperCollider components are able to dispatch actions and receive the appropriate state changes.

Lets look at some examples.

Lights animating in response to state

Lights animating in response to state

As a sequencer plays, the light controller and renderer instances are notified of the state changes and render the lights appropriately.

LightController handles changes in state from the store

LightController handles changes in state from the store

Taking a look at the whole picture, the SuperCollider clock is dispatching these changes in at a strict tempo.

TempoClock dispatching and LightController handling

TempoClock dispatching and LightController handling

Now for a more complicated example, when the knob is turned, the change in meter is "queued" and SuperCollider dispatches the actual change in meter after some time.

Meter change is queued and takes effect next bar

Meter change is queued and takes effect next bar

Meter changes are queued

Meter changes are queued