Host Ports vs. the DAW Port

First instinct was the obvious one: the mio XM has four USB-A ports on the back (USB1-4) already hosting the Argon8, the Little Phatty, and the Radium 49, with one left open. Just run a cable from that open port to the second computer, right?

No. Those four ports are USB host ports, wired to talk to class-compliant USB-MIDI peripherals, synths and controllers, not to hand a MIDI stream to a second computer. The mio XM has exactly one USB port built for that job: a single Type-B "USB-DAW" device port, already spoken for by the laptop. A host port and a device port aren't interchangeable just because they're both USB - plugging a computer into a host port gets you an unrecognized device, not a second DAW connection.

RTP-MIDI Over Ethernet

The mio XM's actual answer to "more than one computer" is its Ethernet port running RTP-MIDI. Confirmed by other iConnectivity users running two separate Windows machines against one mio XM at the same time, each recording independently, sharing the same instruments.

Since the desktop had a spare network port, the cable ran straight from the mio XM to the desktop, no switch in between. That works fine without a crossover cable, modern NICs auto-negotiate (auto-MDI-X), and with no DHCP server on that link both ends just self-assign link-local addresses (169.254.x.x) automatically. RTP-MIDI's discovery (Bonjour/mDNS) works fine over link-local, so there was nothing to configure on the networking side beyond running the cable.

Configured through Auracle, the mio XM exposes its internal routing, the four DIN ports and the four USB host ports, as twelve virtual network ports over that Ethernet connection. Same MIDI data, same routing that already existed inside the box, just a different transport carrying it to a second machine.

rtpMIDI as the Workaround

The fix isn't a Windows 7 build of Auracle, it's not needing Auracle on that machine at all. Auracle only has to run once, anywhere, to set up the mio XM's routing and RTP-MIDI session - it doesn't need to stay running on every machine that connects to it.

What the Windows 7 box actually needs is a way to join that session, and that's a different, much older piece of software: Tobias Erichsen's rtpMIDI driver, which lists Windows 7 through 10 as supported and installed clean.

It's a driver plus a small config app bundled together, not a Start Menu program, look for the desktop icon rtpMIDI drops during install. The panel splits into two lists that aren't obviously related to each other:

• My Sessions - empty by default. You have to create your own local session with the + button, name it, and check its box to activate it before anything else works.
• Directory - this is where the mio XM's twelve broadcast ports actually show up.

Seeing devices in Directory with nothing in My Sessions is the trap: you can't connect a Directory peer to nothing. Create a session first, then go back to Directory, pick the peer, hit connect. It shows up as a participant under your session, and that session name is what Reaper sees as a MIDI device.

Then It Stopped Working

That setup ran fine for a while, then rtpMIDI just stopped connecting. The Directory panel showed the session attempting a connection to a 192.168.x.x address that had nothing to do with the actual setup, when the mio XM's own Auracle page confirmed it was still sitting at its usual link-local address, 169.254.85.228. Nothing in the config was manually set to that address anywhere: not the mio XM, not a hosts file entry, not a saved session with a typed-in IP.

Ruled out, in order: the Windows Bonjour service (restarted it, no change), a stale hosts file entry (nothing there), rtpMIDI's own session cache (fully quit the app rather than just closing the session, no change), and finally a full reboot of the Windows 7 box (no change either). Whatever was holding onto that address survived a complete restart of everything involved.

The reason a reboot didn't fix it: rtpMIDI isn't just the tray app, it installs as an actual Windows service, rtpMIDISvc.exe, that starts on boot independently of the config panel. The panel is a client talking to that service, and a remembered peer connection lives in the service's own state, not the GUI's session list. Closing a session in the tray app doesn't necessarily clear what the service remembers about a peer it already reconnected to once.

Static IP or Bust

Editing security policy or the registry to relabel an "Unidentified network" felt like the wrong amount of effort for a point-to-point MIDI cable that has no reason to touch Windows' network identification logic at all. The simpler fix skips Bonjour discovery entirely instead of fighting Windows over it:

1. On the mio XM's Auracle RTP page, toggled "Set as Static" and gave it a fixed address, 169.254.1.10.
2. On the Windows 7 box's ethernet adapter properties, set a matching static IP in the same subnet, 169.254.1.11, mask 255.255.0.0, gateway left blank.
3. In rtpMIDI, instead of waiting for the peer to show up in Directory via mDNS, used the + button to add it manually by IP address and port.

That's a direct unicast connection by address, no multicast discovery involved, so the Public-network firewall block that killed Bonjour is irrelevant to it. It also means the connection can't drift the way an auto-assigned link-local address theoretically could, both ends are pinned exactly where expected every time.

Recreating every connection from scratch with distinct names fixed it. Final config skips Bonjour entirely and runs both ends on manually assigned static IPs:

• mio XM: 192.168.44.4
• Windows 7 desktop: 192.168.44.44

Each synth chain gets its own local session and peer pair, named for the synth instead of both saying "mioxm," with the session's port always two below its peer's:

• Electribe ESX-1 + microKORG chain: peer port 5004, session port 5002
• Dave Smith Poly Evolver: peer port 5006, session port 5004
• Alesis Micron: peer port 5008, session port 5006
• Yamaha PSR-730: peer port 5010, session port 5008
• Modal Argon8: peer port 5012, session port 5010
• Moog Little Phatty: peer port 5014, session port 5012

With six uniquely-named sessions in place, Reaper's MIDI Devices list finally showed six separate outputs instead of one. Each got enabled for output only, with "send clock" left unchecked on all of them, closing out the false-positive LED from earlier. Reaper now records all six synths at once, at the same time Ableton Live is using the mio XM over its own USB connection.

The difference isn't the routing pattern, every synth has it, it's the Poly Evolver's own MIDI Out jack. Without a dedicated MIDI Thru port, its Out merges anything it generates itself with whatever it's currently receiving on its In, acting as a combined Out+Thru. With that self-loop route sitting on DIN2, the mio XM was already forwarding anything hitting the Poly Evolver's In right back out to it, and the Poly Evolver's own merge behavior gave that loop something to actually sustain itself on. Whatever the other synths do with an identical route, their MIDI Out apparently doesn't merge received data back out the same way, so the loop never has anything to carry.

Note data alone didn't keep it going the way it kept going, which is what made this one hard to place. The message types that actually loop forever are the MIDI System Real-Time ones: Start, Stop, Continue, and Timing Clock. Those exist specifically to pass through gear transparently, that's the whole point of daisy-chaining sync hardware, and Clock in particular streams constantly during playback instead of firing once, which is why this reads as continuous feedback rather than one stray retrigger.

Fix: keep the DIN2 self-loop route if there's ever a reason to want it, but in Auracle's Filter & Remap page, select DIN2 as the Input and filter all four Real-Time types, Start, Stop, Continue, and Timing Clock. Filtering just Start, Stop, and Continue wasn't enough on its own, Clock alone was sufficient to keep the loop alive. With all four blocked on that input, the feedback stopped.

Ableton Link Instead

The thing that actually does transport and tempo sync reliably is Ableton Link, and it has nothing to do with the mio XM setup at all - it's a separate network protocol (UDP multicast, no dedicated cable needed) that just requires both machines to be reachable on the same LAN.

That "reachable on the same LAN" part mattered here specifically because the desktop's Ethernet port was already committed to the point-to-point cable to the mio XM, which is an isolated link-local connection, not part of the regular network. Link's discovery traffic has no way to reach the laptop over that cable. The fix was checking whether the desktop had a second interface free, wifi in this case, so Ethernet stays dedicated to the mio XM and wifi carries Link to the rest of the LAN. Two independent paths, no conflict.

Setup:

1. Live already has Link built in: Preferences > Link/Tempo/MIDI, turn it on.
2. Reaper needs an extension for it, since Link isn't native there. Installed ReaPack (Reaper's package manager) by dropping reaper_reapack64.dll into Reaper's UserPlugins folder (Options > Show REAPER resource path in explorer... to find it) and restarting.
3. Through ReaPack's package browser, installed ReaBlink.
4. From the Actions list, ran Start ReaBlink Monitor - this is the action that actually turns on Link listening/broadcasting for Reaper.

With Link on in both apps and the desktop's wifi confirmed on the same network as the laptop, hitting play in Live should move Reaper's transport with it. Testing that live is next.¹

Reaper's Tempo Goes Sideways

ASIO4ALL on this laptop turned out to be its own project. Audio stuttered badly enough to be unusable, and the usual first fix, bumping the buffer size, did nothing, which is a sign the problem isn't buffer headroom, it's something eating CPU or interrupts underneath it (power plan on Balanced instead of High Performance, a driver-level DPC latency spike from wifi or USB, that kind of thing, still unresolved as of this post).

With ASIO4ALL stable enough to at least get Link connected, a new problem showed up that had nothing to do with audio dropouts: the moment Link actually found Reaper as a peer and started driving its transport, playback tempo went unstable, and Reaper started throwing in what looked like a stray pre-roll with blank audio items appearing. Reaper's own transport genuinely was following Ableton's play button by this point, so the connection itself worked. The tempo feeding into it didn't.

Working theory at the time: ReaBlink is a community Lua-script implementation of Link bolted onto Reaper, not something built into Reaper's core timing the way Link is native to Live, so maybe its polling loop just wasn't tight enough on a fifteen-year-old Windows 7 box to report clean tempo into the shared session. Turned out to be wrong, see below.

Hunting for ReaBlink's Other Scripts

ReaBlink's own documentation has a specific note for exactly this shape of problem: with only one ReaBlink instance in a Link session, explicitly setting it to Master mode (instead of the Puppet/follower mode that the bundled "Start ReaBlink Monitor" action sets up) is called out as a fix. Only one action showed up in Reaper's action list after installing through ReaPack though: Monitor. Nothing for toggling Master, Puppet, sync, or anything else.

Turns out ReaPack only installed the compiled extension plus that one bundled script. The rest of ReaBlink's individual control scripts, ReaBlink_ToggleMaster.lua, ReaBlink_TogglePuppet.lua, ReaBlink_ToggleEnabled.lua, ReaBlink_ToggleStartStopSync.lua, live in the project's GitHub repo under /scripts but aren't part of what ReaPack pulls down automatically. Fix was manual: pull each file's raw content straight from GitHub, save it as a .lua file into the same Scripts folder ReaPack had already created, then load each one individually in Reaper through Actions > New action... > Load ReaScript.... Four extra trips through that dialog, one per file, and all four show up in the action list afterward same as any other script.

Wrap-Up

The lesson isn't really about MIDI, it's that leftover config from an earlier abandoned approach doesn't just sit there inert, it can actively fight whatever you build next on the same wire. The MIDI Clock idea got ruled out early in this post, but the setting that idea required was never cleaned up, and it took a full detour through ReaBlink's Puppet/Master modes to notice the actual conflict was one checkbox away in a completely different preferences pane.

RTP-MIDI over the mio XM stays in the setup regardless, it's still the right way to get a second machine onto shared instruments. Link plus ReaBlink now handles transport and tempo cleanly on top of it, Puppet on, Master off, and nothing left sending a competing clock into the session.

The ASIO4ALL buffer bump from earlier turned out to be a red herring too, set back down to its original size afterward with no problems. Whatever looked like an audio stability issue at the time was likely the same stray clock signal muddying things, not the buffer.