The Client’s Challenge

A client contacted me in a state of deep frustration, and understandably so. He was running Pro Tools on a powerful 2023 M1 Mac with macOS Ventura—a setup that should have been flying. Instead, he was facing a maddening duo of problems: Pro Tools was taking an eternity to load, and once it finally opened, none of his MIDI controllers would register. Not a single note would trigger his AAX instruments.

The Investigation: Uncovering the Real Culprit

Once connected remotely, I began my diagnosis. My first observation was that Pro Tools was set to run in ‘Rosetta’ mode. Rosetta is Apple’s translation layer that allows software written for older Intel processors to run on their new M series Silicon chips. While useful, it’s a potential performance bottleneck and generally unnecessary unless you rely on very old plugins. I made a mental note of this but suspected it was a symptom, not the cause.

The key to solving problems like this is to determine if the issue is with the application (Pro Tools) or the system itself (macOS). The most direct way to test this is to bypass the DAW entirely and go straight to the source: Apple’s own Audio MIDI Setup utility.

This was our breakthrough. The problem wasn’t in Pro Tools at all. The very core of the Mac’s MIDI service was failing. Pro Tools was slow to load because it was waiting indefinitely for a response from a broken MIDI server. The reason the MIDI keyboards didn’t work was simple: the system component responsible for managing them was crashing on startup. It’s like discovering your car won’t start not because of an engine fault, but because the road it’s on has collapsed.

The Fix: Clearing Out Corrupted Drivers

With the root cause identified as a system-level MIDI conflict, the next step was to inspect the Mac’s MIDI driver folder. These are small plugin files that allow the OS to communicate with specific hardware or virtual MIDI networks. An outdated or corrupted driver here is the most common cause of a MIDI Server crash.

1. 1

   I navigated to the system folder where these drivers reside: /Library/Audio/MIDI Drivers/.

2. 2

   Inside, we found three items: a driver for a MOTU device, an unidentifiable ‘RDUSB’ device, and a driver for Waves SoundGrid. The client confirmed he no longer used the MOTU device, didn’t recognise the second, and never used SoundGrid.

3. 3

   The Waves SoundGrid driver was the most likely suspect. It was likely installed unintentionally during a Waves Central update. If the driver was unlicensed or in demo mode, it would try to authenticate itself every time the MIDI Server launched. Because the Audio MIDI Setup utility has no interface for displaying license errors, the driver would simply hang, waiting for a user response that could never be given, and silently crash the whole service.

4. 4

   We removed all three files from the folder and performed a full system restart.

The result was instantaneous. MIDI Studio loaded perfectly. We then launched Pro Tools, which opened swiftly and, to the client’s delight, immediately responded to his MIDI keyboards. The problem was solved.

A Note on Rosetta vs. Native Silicon

As a final optimisation, we returned to the first clue—Pro Tools running in Rosetta mode. Since the client wasn’t using any legacy Intel-only plugins, there was no reason to run the application through this translation layer. We disabled Rosetta, allowing Pro Tools to run ‘natively’ on the M1 chip. This ensures the best possible performance and stability, taking full advantage of the power of his new machine. This final step moved his system from simply ‘working’ to ‘working optimally’.