Blog Routing 9 min read

Route One Controller Into Two DAWs — Multi-Port MIDI Setup

One controller, two hosts, no cross-talk. Route MIDI to two DAWs with separate virtual ports on macOS, Windows and Linux, and keep the bindings clean.

By Aidxn Design

Wanting to route MIDI to two DAWs from one controller is the classic audio-visual problem: one pair of hands, two pieces of software that both want them. Ableton needs clip launches, Resolume needs layer crossfades, and there is exactly one controller on the table. The good news is that virtual MIDI ports are multi-client on every desktop operating system — two hosts can read the same port at the same time. The better news is that you usually should not do it that way. This guide covers both approaches, the reason a port per host wins, and the exact steps on macOS, Windows and Linux.

TL;DR
  • Two patterns: broadcast everything to every port, or assign each binding to a target port.
  • Use a port per host. Channel filtering works, but it is configuration you maintain forever.
  • macOS: add IAC buses. Windows: add loopMIDI ports. Linux: just aconnect twice.
  • Feedback traffic gets its own port so haptics from one host never reach the other.
  • Multi-port fan-out is a Pro feature — the free tier runs one port, one controller.

Can one MIDI controller control two DAWs at once?

Yes — virtual MIDI ports on macOS, Windows and Linux are all multi-client, so two hosts can open and read the same port simultaneously.

On macOS an IAC bus is visible to every CoreMIDI client at once. On Windows the teVirtualMIDI driver underneath loopMIDI and bundled app ports is explicitly multi-client, which older vendor drivers from the Roland and M-Audio era frequently were not. On Linux an ALSA source port can have any number of subscribers; aconnect simply adds another.

So the technical answer is yes and it has been yes for years. The design question — one shared port or one port per host — is where the actual decision lives.

Should I use one port or one port per host?

One port per host, because different applications interpret the same CC numbers differently and channel filtering is configuration you have to maintain in both hosts indefinitely.

Signal flow diagram: One controller to Bridge to Two virtual ports to Two hosts. One controller single physical source Bridge splits by binding Two virtual ports Port A and Port B Two hosts each armed to its own p…
One source, two ports, two hosts. The split happens in the bridge, not in each DAW's filtering.
ApproachSetup effortCross-talk riskMaintenanceBest for
One shared port, channel filteringLowestModerate — hosts see all trafficFilters in every hostQuick tests, two hosts that behave
One port per host (broadcast)LowLowMinimalMost live A/V rigs
One port per host (per-binding)HighestNoneA routing table you ownComplex shows, many controls
Separate port for feedbackOne extra portRemoves echo loopsSet onceHaptics, LED or rumble return paths

The failure mode with a single shared port is subtle rather than dramatic. Everything works in rehearsal, and then one evening a CC you added for a filter sweep also happens to be mapped in the visuals host, and a breakdown turns the projection black. Separate ports make that class of accident structurally impossible.

How do I create the second port?

Add it in the bridge's port settings on any platform, and on macOS or Windows you can also create system-level buses that exist independently of the app.

In the bridge

Open Settings → MIDI → Ports and add a port. The default is Universal Controller; a second becomes Universal Controller 2 unless you name it. Names beat numbers — Universal Controller VJ tells you what it feeds. The port list is expressed as plain configuration:

{
  "ports": [
    { "name": "Universal Controller", "type": "midi" },
    { "name": "Universal Controller VJ", "type": "midi" },
    { "name": "VJ Net", "type": "osc", "target": "127.0.0.1:7000" }
  ]
}

macOS — extra IAC buses

  1. Command-Space → Audio MIDI Setup → Return.
  2. Window → Show MIDI Studio (Command-2).
  3. Double-click IAC Driver and tick Device is online.
  4. Under Ports, click + once per destination host.
  5. Name each bus after its job — UCM Audio, UCM VJ — and click Apply.

Details and the fleet-scripting shortcut: the IAC Driver guide.

Windows — extra loopMIDI ports

  1. Open loopMIDI.
  2. Type a name in the field at the bottom — UCM VJ.
  3. Click +. Repeat per destination.
  4. Leave loopMIDI running in the tray; its ports are recreated at boot.

If the bridge's own bundled teVirtualMIDI port already exists, you only need loopMIDI for the additional buses. Background on that driver: the teVirtualMIDI guide.

Linux — no extra ports required

# See what exists
aconnect -l

# One source, two subscribers — no second port needed
aconnect "Universal Controller:0" "Ardour:0"
aconnect "Universal Controller:0" "Resolume:0"

# Confirm both subscriptions are live
aconnect -l | grep -A3 "Universal Controller"

How do I arm each host against its own port?

Enable the port on the input side of each host — the hosts are reading, so a port enabled as an output will look connected and carry nothing.

  • Ableton Live: Preferences → Link, Tempo & MIDI → set Track ON for its port, plus Remote if you MIDI-map. Leave Sync off unless the controller drives tempo.
  • Resolume: Preferences → MIDI → enable the device, then use the MIDI-map mode to bind clips and sliders.
  • TouchDesigner: add a MIDI In CHOP (or MIDI In DAT) and select the port in the MIDI Device Mapper.
  • Reaper: Preferences → MIDI Devices → right-click → Enable input.
  • Bitwig: Settings → Controllers → add a Generic MIDI controller for the relevant port.

How do I assign bindings to different ports?

Set the target port per binding in the mapping editor, and give a binding two outputs when you want one physical gesture to move both hosts together.

A workable starting layout for an audio-plus-visuals rig:

InputOutput typeTargetChannel / CCPurpose
Face buttonsMIDI NoteUniversal Controllerch 1, notes 36–39Clip launch in the DAW
D-padMIDI NoteUniversal Controller VJch 1, notes 60–63Layer triggers in the visuals host
Right stick X/YMIDI CCUniversal Controllerch 1, CC 1 / CC 2Mod and expression
Left stick X/YOSC/composition/layer1/x—Visual position
Left triggerMIDI CC + OSCBoth targetsCC 7 + /composition/masterOne-gesture A/V crossfade
Right triggerMIDI CCUniversal Controllerch 1, CC 11Expression / master level
Touchpad XYOSC/td/touch/n—Particle field control

The dual-output row is the one worth stealing. A single trigger pull sending CC 7 to the DAW and /composition/master to the visuals host means the whole show dims together on one gesture — the kind of thing that is trivial to configure and impossible to perform reliably any other way. Note that OSC output and multi-port fan-out are both Pro features; the Pro vs Free breakdown has the complete split.

How do I avoid MIDI feedback loops?

Give any host-to-bridge return traffic its own dedicated port so feedback is never rebroadcast into the other host.

Feedback paths are increasingly common — rumble and adaptive-trigger haptics driven by the DAW, LED colour driven by scene state. The risk is that a message arriving on a shared port gets fanned back out, and you end up with an echo that looks like a stuck control. A separate feedback port makes the direction of travel explicit. Channel filtering is a second line of defence, not a replacement for separation. More on the return path in bidirectional MIDI and haptics.

Will two DAWs double my latency?

No — the fan-out happens inside the bridge before the virtual ports, so each host receives its own copy independently rather than queueing behind the other.

What does change is CPU load, since you are now running two hosts. If timing feels worse after adding a second host, look at audio buffer sizes and background load first; the latency tuning docs break the chain into stages so you can tell which one actually moved.

What about two computers instead of two apps?

That is a network MIDI problem rather than a multi-port problem — use a Network MIDI Session on macOS or rtpMIDI on Windows, covered in our MIDI-over-network guide.

Frequently asked questions

Can one MIDI controller control two DAWs at once?

Yes — virtual MIDI ports on all three operating systems are multi-client, so two hosts can listen to the same port simultaneously, and a dedicated port per host is cleaner still.

Should I use one port with channel filtering or two separate ports?

Two ports, because different hosts interpret the same CC numbers differently and channel filtering is extra configuration you have to maintain in both hosts forever.

How do I route a controller to Ableton and Resolume at the same time?

Create two virtual ports, arm Ableton against the first and Resolume against the second, then assign each binding to the port whose host should receive it — or to both when you want a single gesture to move both.

Is multi-port routing available in the free tier?

No — the free tier of Universal Controller MIDI runs one port and one controller, while multi-port fan-out and multi-controller routing are Pro features.

Will routing to two DAWs double my latency?

No, the fan-out happens inside the bridge before the virtual ports, so each host receives its copy independently rather than one waiting behind the other.

Can I route one controller to two different computers?

Yes, by sending MIDI over the network with a Network MIDI Session on macOS or rtpMIDI on Windows, which is a different setup from local multi-port routing.

Build it

Two ports, two hosts, one controller, one crossfade gesture that moves both worlds. It takes about ten minutes to set up and it is the difference between an A/V set you perform and an A/V set you babysit.

Download Universal Controller MIDI to start — the free tier gets one port and one controller working so you can confirm the chain, and Pro at $89 one-time unlocks multi-port fan-out, OSC output and multi-controller routing. Next: the multi-DAW docs or creating virtual MIDI ports from scratch.

Keep reading

More setup walkthroughs