If you have ever installed loopMIDI, rtpMIDI, or a music app that "creates its own MIDI port", you already have teVirtualMIDI on your machine — probably without ever seeing the name. It is the signed Windows driver that makes software-created MIDI ports possible at all, and when a Windows MIDI setup breaks in a way that makes no sense, this driver is usually the layer to inspect. This is the practical guide: what it is, how to confirm it is healthy, how to repair it, and what to do when your organisation's security tooling refuses to let it install.
- teVirtualMIDI is a signed Windows driver by Tobias Erichsen that lets apps publish named virtual MIDI ports.
- loopMIDI and rtpMIDI are built on it — and so is the port Universal Controller MIDI registers during install.
- It is multi-client: two DAWs can read the same port at once.
- When a port is missing, check the driver service first, then the DAW's cached device list, then endpoint security.
- Windows ships no equivalent of its own that is broadly available across Windows 10 and 11 yet.
What is teVirtualMIDI?
teVirtualMIDI is a signed Windows driver by Tobias Erichsen that lets an application create named virtual MIDI ports, and it is the same driver that sits underneath loopMIDI and rtpMIDI.
Windows historically shipped no way for one application to hand MIDI to another. The MIDI stack assumes hardware on the other end of a port. teVirtualMIDI fills that hole by presenting software-created endpoints to the system that look, to every MIDI-aware app, exactly like a physical interface. Your DAW enumerates it alongside your USB keyboard and treats it identically.
Because it is a driver rather than an app, it has no user interface of its own. What you interact with is whatever program sits on top of it — loopMIDI's port list, rtpMIDI's session window, or a music app's settings screen.
Is teVirtualMIDI the same thing as loopMIDI?
No — loopMIDI is a small end-user application for creating ports, while teVirtualMIDI is the underlying driver and developer SDK that loopMIDI and other MIDI applications build on.
The mental model that keeps this straight: the driver is the plumbing in the walls, and loopMIDI is a tap. You can install a different tap, or an appliance that plumbs itself in, but there is one set of pipes. That is why installing two different apps that both bundle teVirtualMIDI does not create a conflict — they share the driver and each registers its own ports.
| Thing | What it is | Has a UI | Creates ports | Typical reason you have it |
|---|---|---|---|---|
| teVirtualMIDI | Kernel driver + SDK | No | On behalf of an app | Came bundled with something |
| loopMIDI | Port-manager app | Yes | Yes, manually named | You followed a tutorial |
| rtpMIDI | Network MIDI app | Yes | Yes, per session | Sending MIDI to a Mac or iPad |
| Universal Controller MIDI | Gamepad-to-MIDI bridge | Yes | Yes, during install | Using a game controller as a MIDI device |
| Windows MIDI Services | Microsoft's newer MIDI stack | Via settings | Yes, first-party API | Not broadly available yet |
How do I check whether teVirtualMIDI is installed?
Query the service and the device objects from PowerShell — if the service exists and the device status reads OK, the driver layer is healthy and any remaining problem is above it.
# Is the driver service present?
Get-Service | Where-Object Name -like "*teVirtualMIDI*"
# Does the virtual port device object exist, and is it healthy?
Get-PnpDevice -Class MEDIA | Where-Object FriendlyName -like "*Universal Controller*"
# Check signing status and version of the installed driver
Get-CimInstance Win32_PnPSignedDriver |
Where-Object DeviceName -like "*Universal*" |
Select-Object DeviceName, DriverVersion, IsSignedA status of OK means the port is registered with Windows. A status of Error means the install was interrupted or rolled back — jump to the repair section below. No results at all means the driver never installed, which is a different problem with a different fix.
How does Universal Controller MIDI use it?
The Windows installer registers a signed teVirtualMIDI port during setup, and the app falls back through a tiered chain if that port is not available.
Being honest about the tiers matters, because "it just works" is not true on every Windows machine — corporate images and aggressive endpoint-detection agents regularly intercept driver installs:
- Tier 1 — bundled driver. The
teVirtualMIDIport registers at install time and appears in your DAW's input list. This is the normal path and it needs no second download. - Tier 2 — immediate audible fallback. If no routable port is available, the app plays through the Microsoft GS Wavetable Synth that ships with every Windows install, so pressing a button makes a sound straight away. It proves the controller and the mapping work; it is not a route into a DAW.
- Tier 3 — manual fallback. Install loopMIDI, create a port named exactly
Universal Controller MIDI, restart the app, and it routes to that port automatically.
On macOS and Linux none of this applies — CoreMIDI and ALSA both let an application publish a port with no driver install at all. The Windows virtual port docs carry the full matrix, and the cross-platform setup guide covers the other two operating systems.
How do I repair a broken teVirtualMIDI install?
Remove the stale driver package with pnputil /delete-driver and reinstall it from the application's bundled INF, then reboot.
# Run this from an ELEVATED PowerShell window
$drv = "$env:LOCALAPPDATA\Programs\UniversalControllerMIDI\driver\teVirtualMIDI64.inf"
# Find and remove any existing oem*.inf for the driver
pnputil /enum-drivers | Select-String -Context 0,7 "teVirtualMIDI" |
ForEach-Object { ($_ -split ":")[1].Trim() } |
Where-Object { $_ -like "oem*.inf" } |
ForEach-Object { pnputil /delete-driver $_ /uninstall /force }
# Install fresh from the bundled package
pnputil /add-driver $drv /install
# Force a device rescan (helps after a Secure Boot cache miss)
pnputil /scan-devicesReboot after this. Windows caches MIDI device names aggressively and some DAWs — FL Studio is the usual example — keep showing an old port name until both the OS and the DAW have restarted.
Why does my virtual MIDI port not appear in my DAW?
Most often the driver install was blocked by endpoint-security software, or the DAW cached its MIDI device list at startup and needs a restart to see the new port.
Work the list in this order — it is ordered by how often each one is the actual cause:
- Restart the DAW. Nearly every host enumerates MIDI devices once, at launch. Create the port, then start the DAW.
- Check you enabled the input, not the output. Your DAW reads from the port, so it belongs on the input side. Ableton needs Track on, plus Remote if you want to MIDI-map.
- Confirm the device status is OK with the PowerShell snippet above. Status Error means repair the driver.
- Look for a name collision. Two ports with the same name — one from a stale loopMIDI entry, one from the app — produce exactly the behaviour you would expect: you keep picking the dead one.
- Check channel filtering. A port that is working perfectly will look dead if the receiving track only listens to channel 2 and the source transmits on channel 1. Set the track to All Channels while testing.
The longer decision tree, including the duplicated-notes and device-busy cases, lives in our MIDI port troubleshooting guide.
Does teVirtualMIDI support two DAWs at once?
Yes — the driver is multi-client, so two applications can open the same virtual port simultaneously, which older vendor MIDI drivers frequently could not.
That matters for anyone running an audio host and a visuals host together. You can arm Ableton and Resolume against the same port and both receive every event, then filter by channel or CC inside each host. The cleaner approach for anything beyond a simple setup is a dedicated port per host, which is covered in routing one controller to multiple DAWs. Note that multi-port fan-out in Universal Controller MIDI is a Pro feature; the free tier runs one port and one controller.
Frequently asked questions
What is teVirtualMIDI?
teVirtualMIDI is a signed Windows driver by Tobias Erichsen that lets an application create named virtual MIDI ports, and it is the same driver that sits underneath loopMIDI and rtpMIDI.
Is teVirtualMIDI the same thing as loopMIDI?
No — loopMIDI is a small end-user application for creating ports, while teVirtualMIDI is the underlying driver and developer SDK that loopMIDI and other MIDI applications build on.
Do I need to download teVirtualMIDI separately?
Normally not, because it arrives bundled inside an application installer such as loopMIDI, rtpMIDI, or Universal Controller MIDI.
Why does my teVirtualMIDI port not appear in my DAW?
Most often the driver install was blocked by endpoint-security software, or the DAW cached its MIDI device list at startup and needs a restart to see the new port.
Does teVirtualMIDI support more than one application at a time?
Yes, the driver is multi-client, so two DAWs can listen to the same virtual port simultaneously — older vendor MIDI drivers often could not do that.
Will Windows MIDI Services replace teVirtualMIDI?
Eventually it should, since Microsoft's newer MIDI stack includes a first-party virtual-port API, but it is not broadly available across Windows 10 and 11 yet, so teVirtualMIDI remains the stack that behaves identically on both.
Where this leaves you
For most people teVirtualMIDI is invisible infrastructure, and that is the correct outcome. You only need to know the name on the day a port goes missing — at which point the PowerShell checks above tell you in thirty seconds whether the problem is the driver or the DAW.
If you are setting this up to get a game controller into your DAW, download Universal Controller MIDI: the Windows installer handles the driver, the app handles the fallbacks, and it works the same way on macOS and Linux where no driver is needed at all. Next: loopMIDI alternatives per platform.