Delete and clean up "used" MIDI ports/channels

Often, old virtual MIDI cables (e.g., from uninstalled programs) remain and "use up" ports that are no longer needed.
Here's how to clean them up properly:

1. Delete old virtual MIDI ports

CoolSoft VirtualMIDISynth: Open the configurator → "MIDI Devices" → remove unused ones.
https://coolsoft.altervista.org/en/virtualmidisynth

MIDI-OX / MIDI Yoke: Under "MIDI Devices", deactivate the ports or uninstall the entire tool.
www.midiox.com

2. Remove hidden / "ghost" MIDI ports (very important!)

Many ports remain in Windows after uninstallation but are simply invisible.
Method A – With MIDI-OX (easiest option)
Download and start MIDI-OX.
Menu → “Options” → “MIDI Devices”.
Switch to “Show all devices including disabled/ghost” (or similar).
Select all grayed-out (disabled) and no longer needed ports → “Remove Device”.

 

I'm using Windoze 10. Yeah, I remembered that I originally ditched the SL because of strange behaviour, but I don't remember how I solved it. Anyway, the S61 has no issues with Midiremote, so I'll assume that there's something wrong with the k/b. And yes, I have noticed that once a port is used by one script, it disappears from your menu choices.

 

I hear you, but I've had this computer for almost ten years, so there's zero chance of me doing things in the order you suggest.

 

Thanks, but how do I go back to correct this without uninstalling things? I did notice that there were several midi ports named MIDIIN2, but they had stuff like (SLMKII) or (TAPCO) after them in the name. It's difficult to understand why the behaviour you speak of is allowed to go on, plus that you can't go directly to the surface editor and change the ports.

 

@Doggy, perhaps these two AI answers will help you; I know it's a lot of text and the AI sometimes gets things mixed up:

Spoiler: Source: Grok KI

You’re actually very close to fixing this without uninstalling anything — the multiple “MIDIIN2” (and MIDIOUT2) ports with different names in parentheses are exactly why Ableton is getting confused. Windows is assigning the same generic port numbers (MIDIIN2/MIDIOUT2) to every new device that gets plugged in, and Ableton just shows the numbers, not the friendly names in parentheses. That’s the infamous “MIDI port conflict” bug that has plagued Ableton on Windows for years (and yes, it’s infuriating that they still haven’t added a proper dropdown with the full device names like every other DAW).

Here are the quickest ways to fix it without uninstalling drivers or the devices themselves:

Method 1: The 5-second fix (works 90% of the time)

1. Open Ableton → Preferences → Link/MIDI
2. In the MIDI Ports list, turn Track and Remote OFF for every single entry that says MIDIIN2 or MIDIOUT2 (even the ones you want to keep).
3. Click OK to close Preferences (this forces Ableton to release the ports).
4. Re-open Preferences → Link/MIDI
5. Now turn Track (and Sync if you need it) back ON only for the exact ports that belong to your SL MkII (you’ll recognize them because the moment you enable them, the orange light on the SL will come on, or the TAPCO will light up, etc.).

Ableton will now remember the correct ones even if Windows still calls them all “MIDIIN2”.

Method 2: Force Windows to give them unique numbers (so it never happens again)

1. Open Device Manager (Win + X → Device Manager)
2. Go to View → Show hidden devices
3. Expand “Sound, video and game controllers” and “Universal Serial Bus devices”
4. You’ll see a bunch of greyed-out (ghost) entries for your SL MkII, TAPCO, etc. from previous plug-ins.
5. Right-click and Uninstall every greyed-out duplicate (leave the ones that are not greyed-out).
6. Unplug all MIDI devices, restart the computer, then plug them back in one by one. → Windows will now assign MIDIIN2 / MIDIOUT2 to the first device, MIDIIN3 / MIDIOUT3 to the second, etc. Ableton will finally see unique numbers.

Method 3: Cheat with MidiOX (if you want to keep the ghost devices)
Download MidiOX → open it → Options → MIDI Devices → you’ll see the real names there. You can then rename the ports in the Windows registry (a bit advanced) or just use MidiOX to see which “MIDIIN2” is which while you toggle them in Ableton.

Most people just do Method 1 every now and then when it gets confused again. It’s stupid that we have to, but it takes literally 10 seconds once you know the trick.

Let me know which devices you actually want to use (SL MkII, TAPCO, etc.) and I can tell you exactly which ports to enable after you do the reset.

Spoiler: Source: Grok KI - 2

The problem you’re describing now is classic MIDI feedback loop + control-surface conflict caused by the new MOTU 828 adding its own MIDI ports (and probably leaving the old “MIDIIN2 (SLMKII)” still active in Cubase).

When two (or more) devices share the exact same port name in Windows, Cubase still treats them as separate surfaces behind the scenes, but the MIDI routing gets completely scrambled → buttons send on one port, Cubase answers back on another, the SL MkII sees its own outgoing messages coming back in → instant chaos (pan moves faders, faders arm tracks, info line flickers, etc.).

You don’t have to uninstall drivers or lose your remote script. Here’s the exact sequence that fixes it 99 % of the time in Cubase (I’ve done this hundreds of times with SL MkII + MOTU + other interfaces):

Quick Fix Inside Cubase Only (5–10 minutes, no uninstalling)

1. Studio → Studio Setup → MIDI Port Setup → Untick “In ‘All MIDI Inputs’” for every single entry that contains
   • Novation SL MkII
   • Automap
   • MOTU
   • Anything that says MIDIIN2 / MIDIIN3 etc. (Basically disable everything temporarily)
2. Under “Remote Devices”
   • Select your “Novation SL MkII” entry (or whatever you named your custom script)
   • Set both MIDI Input and MIDI Output to “Not connected”
   • Do the same for “Mackie Control” or any generic surface that might still be there
   • Click Apply
3. Close Studio Setup completely, then reopen it.
4. Now re-enable only the ports that really belong to the SL MkII:
   • Go back to MIDI Port Setup
   • Put a tick in “In ‘All MIDI Inputs’” only for the one line that says something like “MIDIIN2 (Novation SL MkII)” or “MIDIIN3 (Novation SL MkII)”
   • Make sure no other duplicate MIDIIN2/MIDIIN3 lines are ticked
   • Leave the MOTU ports visible if you want them for other things, but don’t tick them in “All MIDI Inputs” unless you actually use them as a controller
5. Remote Devices again → select your SL MkII surface → MIDI Input: choose the exact same port you just ticked above (the one with (Novation SL MkII) in the name) → MIDI Output: choose the matching output port that has (Novation SL MkII) in the name → Click Apply
6. Restart Cubase (important – it has to fully release and re-grab the ports).

After restart, your script will work again and the feedback loop will be gone. The flickering info line and crossed controls disappear instantly once Cubase is talking exclusively to the correct port pair.

Optional (to prevent it ever happening again)
In Windows Device Manager → View → Show hidden devices → uninstall all the greyed-out duplicate Novation/MOTU entries. Then plug the SL MkII in first (before the 828) after a reboot so it grabs MIDIIN2 permanently and the MOTU gets MIDIIN3 or higher.

That’s it – no need to touch your remote script or reinstall anything. Let me know what the exact port names are in your MIDI Port Setup list right now and I can tell you exactly which one to tick/untick.

Spoiler: Source: Perplexity KI

What you are seeing with names like MIDIIN2 (SLMKII) or MIDIIN2 (TAPCO) is normal on Windows: those “2” ports are usually a second virtual MIDI endpoint exposed by the device (often for things like control surfaces, MIDI thru, or editor/firmware communication), and DAWs/surface editors can get confused if the wrong one is selected.

How to revert without uninstalling
Try these steps first; they do not require uninstalling software:

1. In your DAW’s MIDI/device preferences
   
   • Open the MIDI or control-surface settings.
     
     
   • For the control surface you set up, change its input and output back to the original device names if they still appear, or try the non‑MIDIIN2 versions (for example, SLMKII instead of MIDIIN2 (SLMKII)).
     
     
   • Disable any extra ports you are not sure about for that surface, so only one input and one output are active.
     
2. In the control‑surface/editor utility
   
   • If the editor has a “MIDI Settings” or “Device Setup” page, set:
     
     • Input: the basic device name (e.g. SLMKII).
       
       
     • Output: the same, and avoid the (Port 2) / MIDIIN2 variants unless the manual explicitly says to use them.
       
3. Power‑cycle and re‑plug only once
   
   • Turn the controller off.
     
     
   • Close the DAW and the surface editor.
     
     
   • Turn the controller on, wait a few seconds, then open the editor, choose the correct ports, and finally open the DAW so both see the same pair of ports.
     

If port names are a mess
If the names have become confusing but everything still “sort of works”:

• Leave the driver installed, but:
  
  • Disconnect the MIDI device.
    
    
  • In Windows Device Manager, remove only duplicate or obviously stale entries for that device (grayed‑out ones), then scan for hardware changes and plug the device back in once.
    
• This often forces Windows to drop old “ghost” port instances without a full uninstall of your music software.
  

Why this odd behavior exists
Windows tends to create a new logical MIDI port entry whenever a USB MIDI device is seen as “different” (new port, different driver state, etc.), which is why you end up with MIDIIN2 (SLMKII), MIDIIN3, and so on. Many controllers also expose multiple ports by design (keys, DAW/control, MIDI thru), but DAWs and editors do not always make it obvious which one is meant for control‑surface communication, and they often do not let you jump straight into an editor from the control‑surface page to fix a bad port choice.

If you tell which DAW and which controller/surface editor you are using (e.g. “Cakewalk + Novation SL MKII” or “Cubase + TAPCO”), a precise “click‑here, choose‑this‑port” set of steps can be outlined.

 

I am sure you could do that, and you could follow the advice to use MidiOX or other Midi utility like that. But as long as your Motu 828 is not damaged/malfunctioning like say for instance you bought it used and untested; all of those workarounds are going to cost you time in the long run. If it is a perfectly functioning device, installing it and getting it right from the start will save you headaches in the long run. Which version of Cubase are you using?

This is how I would tackle the problem. My first attempt at a fix would be to remove the devices. Reboot the machine. Reset cubase to default fresh install settings. Then reinstall the audio interface again first and get that setup correctly. When you are satisfied the 828 is working properly, reboot. Then install the Novation remote again after that.

Disconnect both MOTU 828 and Novation controller. Reset Cubase 12 by renaming %APPDATA%\Steinberg\Cubase 12_64 and restart Cubase. Plug in the Motu first, confirm it works, then add the Novation controller after that. Getting the Motu working in Cubase will be a piece of cake, and you might not even need to reinstall the software for it. Once that is done, you have your problem narrowed down to only installing your Novation/script correctly with your Motu already "resident" on the machine.

Maybe a Windows user can confirm that approach before you try it. It's an older device so I would consider rebooting after each major step. Cubase cleaned up and default, reboot. 828 working, reboot. You get the idea. I used the Cubase 12 naming convention so depending on your actual version of Cubase you will have to adjust that one thing.

 

Last edited: Dec 5, 2025 at 9:07 PM