Cubase Arturia KeyLab Setup: A MIDI Port Routing Fix
The Client’s Challenge
It’s a moment of profound frustration when a new piece of studio equipment, designed to streamline your creative process, does precisely the opposite. My client, a talented composer, had invested in an Arturia KeyLab Mk2, a powerful and versatile keyboard controller. He had meticulously followed every tutorial and setup guide provided by the manufacturer for integrating it with Cubase.
Yet, the result was chaos. The keyboard seemed to have a mind of its own. Moving a fader might trigger a random piano note. Playing a key could inexplicably adjust a channel’s volume. The very tools meant to give him tactile control over his composition were creating digital anarchy. He was certain he’d made a simple mistake but was completely unable to locate it, a maddening position for any creative professional to be in.
Client’s Environment:
- DAW: Steinberg Cubase
- Hardware: Arturia KeyLab Mk2
- Operating System: Windows
- Symptoms: Cross-functional MIDI control. Faders triggering notes, keys moving faders.
Diagnosis: The Case of the Two Digital Doorways
Connecting remotely, I began my investigation. The symptoms were a classic signature not of a hardware fault, but of a ‘Contextual Conflict’ in how Cubase was interpreting the MIDI data it was receiving. The client had done everything right according to the guides, but one subtle, crucial detail was missing from the documentation he’d seen.
Modern controllers like the KeyLab Mk2 are far more sophisticated than simple MIDI keyboards of the past. They don’t just send one stream of data; they send multiple, distinct streams over different ‘virtual ports’.
Core Concept: Virtual MIDI Ports
Think of your USB cable as a large pipe. Inside that pipe, the KeyLab creates two smaller, separate pipes, which we’ll call Port 1 and Port 2.
- MIDI Port 1 (The Musical Data): This pipe carries all the standard musical information: which key you pressed, how hard you pressed it, and when you let go. It’s for playing virtual instruments. It also handles data coming *in* from the physical MIDI DIN sockets on the back of the keyboard.
- MIDI Port 2 (The Control Data): This pipe is reserved for a special language (like Mackie Control or HUI) that speaks directly to the DAW itself. It carries commands like ‘Play’, ‘Stop’, ‘Record’, and ‘move fader 3’.
The problem arises when the DAW listens to the wrong pipe for the wrong information. The client had correctly told Cubase to expect special control commands, but he had inadvertently pointed it to listen at Port 1. Cubase was hearing the language of faders and transport controls, but trying to interpret it as musical notes—hence the chaos.
The Fix: Directing Traffic to the Correct Port
The solution was to guide Cubase to listen to the correct virtual port for its control information. It’s a simple change, but buried deep within the setup menus. Here is the step-by-step process we followed to restore order.
Step 1: Set the Keyboard Mode
First, ensure the Arturia KeyLab Mk2 itself is in the correct mode. Use the hardware controls to select the ‘DAW’ mode and then specify ‘Cubase’. This tells the keyboard which ‘language’ to send over Port 2.
Step 2: Open Cubase Studio Setup
In Cubase, navigate to the top menu and select Studio > Studio Setup…. This is the central hub for all external hardware configuration.
Step 3: Add a Remote Device
In the top-left corner of the Studio Setup window, click the ‘+’ button to ‘Add Device’. From the list, it’s tempting to look for ‘Control Surface’, but the correct path is to select ‘Mackie HUI’ as Arturia emulates this protocol for Cubase integration. This is a critical point of ambiguity in the setup.
Step 4: The Crucial Port Assignment
With the new Mackie HUI device selected in the left-hand pane, look to the right. You will see dropdown menus for ‘MIDI Input’ and ‘MIDI Output’. This is where the magic happens. Click on the ‘MIDI Input’ dropdown and select the entry that specifically refers to Port 2 of your Arturia keyboard (often named something like ‘MIDIIN2 (KeyLab MkII)’ or ‘KeyLab MkII DAW’). Do the same for the ‘MIDI Output’, selecting the corresponding Port 2 entry. This instructs Cubase to listen for control commands exclusively on the correct channel.
Click image to expand
Step 5: Test and Verify
Click ‘Apply’ and ‘OK’. Now, back in your project, the keyboard will behave as expected. The keys will play notes, the faders will control the mixer, and the transport buttons will control playback. The digital anarchy was resolved.
Additional Reflections: A Feature, Not a Flaw
It’s important to frame this issue correctly. This is not a case of user error or faulty design. The existence of multiple virtual MIDI ports is an incredibly powerful feature that allows for deep, nuanced control of a DAW from a single USB cable. The true issue is one of ‘UI Ambiguity’—the software interfaces for both the hardware and the DAW don’t always make the distinction between these ports clear.
My client’s frustration was entirely justified because the solution was hidden behind a layer of technical knowledge that isn’t immediately obvious from standard user guides. Knowing *that* these ports exist and *why* they are separate is the key that unlocks the problem. Once you have that key, the fix is straightforward. This case is a perfect example of an ‘Edge Case’ where high-level understanding, not just procedural instruction, is required to find the solution.
If you are seeking professional help with this particular Cubase Arturia KeyLab setup, or other complex MIDI port routing and control surface conflicts, one-on-one remote support services are available from Audio Support.
