@work

Here are some projects I loved working on. The ones in the public domain at least. As such, they are mainly user-facing.

The Collective @ Focusrite Group

The Collective is a brand of Focusrite Group. It's a VST plugin brand and platform. We designed the plugins with Sonible, who built them with their AI-powered smart technology.

As part of this project, I contributed to the website and backend infrastructure and (my primary focus) drove the development of a Rust-based library. The library handles DRM for the plugin and allows secure access to our platform for third-party software, including Sonible plugins.

Rust was chosen for a number of reasons:

Security: a DRM library is bad actors' main target.
Strong C interoperability.
It has a solid networking stack in the standard library.
It has fantastic threading primitives and compile-time checks.
It was a chance to introduce Rust into the company with a small, self-contained project.

The plugins were shipped with the Rust library in 2022 and are still on the market.

Rust in prod achieved! 🎉

We worked in a small cross-functional team. Everyone shared and reviewed each others tasks. Amazing learning experience with a fantastic team!

Ampify Studio @ Focusrite Group

Ampify Studio is a fast way of making cool tracks. It's not a DAW. More of a banger track builder. Its unique approach to the embedded sample browser and timeline view (combination of arrangement and clips) just make it feel like something else. Something more fun, fast and intuitive.

There are thousands of Ampify Sound packs to pick from, beautifully produced and curated samples with real-time pitch and time shifting, so you can mix-and-match to make whatever floats your boat.

It's all written in C++, though we managed to sneak a Rust library in there as well ;) While I was part of the project, the main feature we designed and implemented audio recording.

Awesome team, fun product, good times!

ROLI Dashboard @ ROLI

At ROLI, I primarily worked on Dashboard. It allows users to interact and configure their ROLI devices, such as the BLOCKS series. Still love my little Seaboard Block!

The application is in JUCE. It was amazing working there with some brilliant colleagues and the talented JUCE team!

DSP Designer @ DREAM

DREAM designs DSP chips for audio applications. With that, they also make and sell reference designs for complex projects. To accelerate development they have ready-made DSP algorithms and wanted a way to visually build instruments and generate the code for them, ready to be flashed on device.

DSP Designer does just that, and more. I worked on various parts of the software, including the topological graph sorting of the DSP nodes and architecture redesign.

I did my Master's thesis work here, writing DSP algorithms for DREAM. Specifically, various Partitioned Convolution and FFT implementations in C running on their ISA. Testing, benchmarking and optimizing them to optimize the algorithms for minimal time/space footprint.

It's a small company that punches above its weight and makes it work through their decades of experience designing DSP chips for the audio industry.

Shout out to the sound designer (and general savant). Great times geeking out on synths, can't believe we got our hands on a Schmidt!

Cathodique 2.0 @ ISEN

While studying at ISEN Lille, myself and the other Music Tech students worked on an interactive video mapping experience.

The mapping was projected on the facade of the University Catholique of Lille, France.

The show started with 10 minutes of video mapping then 20 minutes where the public could engage in collaborative games on the facade via four Leap Motions installed on pedestals. The show looped all night, many people participated, interacting with the massive projection.

Each game mapped onto the facade. For example, we had a collaborative sequencer where each window was a step and each player controlled a different sound. The players could press a window to activate a sound when the sequencer reached a given window.

@home

At home, I mainly look for side quests to do in Rust and a little bit of Zig nowadays.

aud

aud is a CLI tool to help with audio-related tasks.

It started from just needing to very quickly watch a MIDI input stream. From there I needed some filtering and saving of the messages. So I embedded a Lua runtime with script hot-reloading and runtime reload (if the script is borked). Now it's a "scriptable audio CLI tool" that can hook into audio/midi streams and do loads of things through hot-Lua script, e.g. send/receive data, save-to-disk, etc...

The tool can also be used as a library in C. From there, an application can stream audio as a source to a destination (an aud client). The client can then run a terminal-based oscilloscope and hook into the stream with a Lua script. Currently, it blasts audio over UDP with minimal package validation.

rume

rume is a library for building DSP graphs for virtual instruments in Rust. It comes with some DSP building blocks and some gnarly hand-rolled graph representation and sorting code in Rust, fun :)

At Focusrite/Novation in late 2020, we used it during a hackday to build a synth with tauri as the frontend and rume as the audio engine. Since then, it hasn't gotten much love... In hindsight, I think there are better approaches to solving this type of problem. Going all-in on Rust macros can be painful for the library developer and consumer.

The idea from SOUL/CMajor, it's an experimental rip-off using Rust macros. Realistically, it's more of a Rust exercise. CMajor is far better suited for what this type of graph syntax tries to achieve. Check the language out if you haven't yet!

NixOS

Recently, I've taken the (so far shallow) dive into NixOS. The idea of a declarative, reproducible, and generational Linux OS is amazing. On top of that, the nix shells/envs are a godsend for development without having to spin-up docker containers for every project or install dependencies globally.

You can find my NixOS configuration somewhere in my dotfiles. For the moment I still use other OSes that use the same dotfiles so I have not yet fully committed to the all-in home-manager setup.

I have a few machines setup now with more or less the same config, including a base-model M1 Macbook Air. The setup idles at around 400MB RAM, so the Air with its 8GB RAM and 128GB actually works beautifully. Especially compared to macOS/Windows which idle at around 6GB.

That being said, I've found the non-FHS compliance to be the main hurdle to using it as my daily dev driver. Particularly for compiled programs which use dynamic linker/loader, be ready to patchelf...