Transport Control
Minimal transport control surface for audio recording software.
Back in the days of tape recording studios, audio engineers controlled common transport functions with physical buttons. Play, pause, record, and navigation were all actions with physical feedback.
These days, audio engineers are glued to their keyboards and screens. This is powerful, but can lead to unhealthy habits, awkward workflows, and repetitive stress injuries. The Transport Control lets you give less attention to the tools and more attention to your music.
Existing Solutions
Some of the alternatives:
- Neve 5060 Centerpiece - an all in one control surface and analog summing desk.
- PreSonus FaderPort - a track focused control surface with an automated fader and project navigation.
- Software-specific phone companion apps
- Steinberg CMC TP - Cubase software-specific transport control surface.
All of these options have a few things in common. Often, they try to do too much. The FaderPort, for example, focuses on the performance of the automated fader, and the project navigation features feel like afterthoughts. The FaderPort buttons feel cheap, and often bounce or don't register a button press. On the other hand, products like the Neve 5060 or Focusrite hybrid mixing consoles are extremely expensive because of their feature density. Phone apps, while accessible, are just another screen.
Our Improvements
With these shortfalls in mind, the Transport Control is a focused and minimal transport control surface. It has six functions: Stop, Play, Record, Undo, Move Cursor, and Place Marker, and it does each of these functions reliably and consistently. It requires almost no setup - just plug it in to your computer and enable it in your digital audio workstation (DAW).
Features & Specifications
- Stripped down user interface
- High quality mechanical switches and jog wheel
- DAW-agnostic - USB MIDI compliant and Mackie Control Universal compatible
- USB bus powered, < 100mA current consumption
- Small, desk friendly format: ~ 15 cm x 10 cm
Technical Details
Shown below is an early prototype in development.
User Requirements
| No. | User Requirement | Technical Requirement |
|---|---|---|
| 1 | The controller shall not introduce noticeable latency | The controller shall introduce no more than 20ms of latency from a button press to an "event" |
| 2 | The controller shall provide a user interface to control audio recording and playback | The controller shall offer the user a method to play, stop, record, seek, and undo |
| 3 | The controller shall be compatible with industry-standard protocols and connections | The controller shall generate MIDI output to trigger the actions outlined in Requirement 2 |
| 4 | The controller shall fit comfortably on a desk, alongside other professional audio equipment | The controller shall not exceed 5" by 4" by 2" |
| 5 | The controller shall not exceed reasonable power usage relative to other audio equipment | The controller shall not draw more than 100mA of current from the DC supply |
Hardware
System Diagram
The Transport Control has an STM32F429 at its heart. I chose the STM32F429 for its performance and flexibility with peripherals and I/O. It's overkill for this project, but was a good introduction to the STM32F4 family. The development kit was also inexpensive and very well documented.
The STM32F4's General Purpose Timer peripheral reads the rotary encoder input. The GPIO peripheral reads switches and writes to LEDs. The USBD (USB Device) peripheral and software core provided by ST facilitate all communication with the host computer. One USART is enabled and routed on the PCB for debugging.
Schematic
This system is laid out on a two-layer PCB, shown below. The board is mounted just below the front panel by the switches and encoder, and the USB connector extends to the back of the enclosure.
PCB
Top Layer
Bottom Layer
Software
The Transport Control uses a real time operating system to manage asynchronous human interaction. Each human input source (button, encoder, etc) can generate a MIDI event, which is placed on a queue. The MIDI task pends on this queue, and empties it into the USB peripheral buffers as soon as possible.
Flow Diagram
The Transport Control consists of three tasks: The Button Task, Encoder Task, and MIDI Task. The Button Task and Encoder Task manage user interaction, and communicate with the MIDI task by posting events to a Queue. On receiving a new event, the MIDI Task sends an appropriate USB MIDI Packet.
Button Task
The button task polls each keyswitch and debounces using a state machine.
Encoder Task
The encoder task polls the hardware timers count register, and generates clockwise or counterclockwise "scrub/jog" events accordingly.
MIDI task
The MIDI module initializes the MIDI output queue, implements the MIDI task (shown below), and exposes several utility functions for sending MIDI messages from tasks and interrupts. The MIDI module also contains a header file with common MIDI attributes and Mackie Control Universal compatible notes, velocities, etc.
USB Device
The USB Device module initializes the STM32 USB hardware layer and implements a class compliant USB MIDI Device Class. Most of this module just serves to inform the host computer what kind of device it is, how many data pipes to open, how big the data is, etc. These attributes are all prescribed by the USB MIDI Specification.
Priority and Timing
The three tasks are rate monotonic - meaning that the shortest duration tasks have the highest priority. For the Transport Control, in order of highest to lowest priority:
- Encoder Task
- Button Task
- MIDI Task
This way, a user interaction will always preempt any other CPU activity. In theory, this could lead to queue overflow or consistent blocking of the MIDI output. But in practice, user input on this device is usually in short bursts, and rate monotonic task priority has provided a reliable and consistent feeling when you use the Transport Controller.