Focusrite Control marked my first real software project. As a QA Engineer I'd been teaching myself C++, helping out with maintenance of existing products, and generally nibbling at the heels of the management to give me an opportunity as a software engineer on a new project.
What is Focusrite Control?
Focusrite manufactures audio interfaces. These are (in Focusrite's case, usually red) boxes that you connect to your computer. They sit between your computer and all of the audio equipent in your studio. This might be microphones, instruments and speakers.
These interfaces usually have a built-in mixing and routing facilities to control which signals are sent where. Unlike hardware mixers that might have lots of knobs and sliders to control the settings, the settings are remote controlled using control software. That's where Focusrite Control comes in.
Given my experience in Customer Support and QA at Focusrite, this was an ideal project for me. Its predecessor, Saffire MixControl, had done the job, but I'd been on the front line experiencing customers' frustration as they failed to grasp how to achieve what they wanted in the software. Time for a re-write!
I was paired with a senior engineer and we set about designing the system. Unlike when the previous software was developed, we knew in advance that it would need to control settings for a range of interfaces, rather than just one. We also knew that at some point we'd like the ability to control interfaces remotely using a phone or tablet (more about that here).
With this knowledge, we designed a client-server system. In this system, the client was the user interface and the server was a daemon that would talk to the devices over Thunderbolt. We designed a discovery protocol using UDP and a communication protocol using TCP between the client and the server.
It was around this point, shortly after starting development on the product, that the senior engineer unexepectedly and abruptly left the company. Management decided against making another hire, leaving me and my nascent experience to complete the project as the only software engineer. Terrifying, yes, but in hindsight this turned out to be a definitive moment in my career.
Taking the wrong path
The project was a constant learning experience for me.
I learned about over-engineering.
The UI for Focusrite Control was built using the JUCE framework. I'd been reading about declarative UI frameworks and I liked the idea. I figured that instead of creating the UI in JUCE directly, I'd specify the UI using XML, and create a rendering engine to turn that HTML into JUCE components. Noble.
The system grew quite quickly and I was having fun writing tests and expanding its capabilities. However, its complexity soon started to weigh me down and I was struggling to control a basic UI. In the ended, I decided to scrap the whole system and write a normal UI like a normal person. The new UI went together in no time and was substantially easier to work with. I felt like there was a massive weight off my back!
This is when I learned to pay attention to nagging doubts, even when the 'Sunk Cost Devil' on your shoulder is trying to drown them out.
I started Focusrite Control is 2014 and it was released in 2015 along with the Clarett range of audio interfaces. I later added support for the Red and 2nd Generation Scarlett interfaces. Since I left the team to work on Novation products, support has been added for Clarett USB and 3rd Generation Scarlett interfaces.
Having worked with Focusrite interfaces for many years, I was emotionally invested in this project. I'm proud to see that it's gone on to support so many audio interfaces. I hope that it has made a few musicians' lives easier.