# Hercules DJControl Mix: No MIDI Response (Windows)

**URL:** <https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539>\
**Category:** DJ Hardware\
**Tags:** Windows\
**Created:** [October 17, 2026, 1:52pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539 "2026-10-17T13:52:52Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![fcojbb](https://community.algoriddim.com/letter_avatar_proxy/v4/letter/f/a6a055/32.png) [@fcojbb](https://community.algoriddim.com/u/fcojbb)\
**Post date:** [October 17, 2026, 1:52pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/1 "2026-10-17T13:52:52Z")

</div>

# Djay Pro (Windows) — Hercules DJControl Mix: no control responds, although MIDI is delivered and djay connects

**Category:** Bug Reports / Windows  
**djay version:** 5.6.7040.0 (MSIX `59BEBC1A.djay`)  
**OS:** Windows 11 Home Single Language, 26H2, build 26300.9711  
**Hardware/controllers used:** Hercules DJControl Mix (`VID_06F8&PID_B12D`)  
**Driver:** `HDJusbaudio` 6.1.1.0 (`oem70.inf`), Guillemot Corporation, WHCP-signed

* * *

## A) SUMMARY OF ISSUE

Djay Pro on Windows does not respond to **any** control on the Hercules DJControl  
Mix. Neither the performance pads, nor the faders, nor the crossfader produce any  
action.

The device, the Hercules driver and the Windows MIDI stack all work correctly.  
djay detects the device, accepts the built-in mapping, and opens both MIDI ports  
(input and output) on the correct endpoint. It simply does not act on incoming  
messages.

This was verified with Microsoft’s own `midi1monitor` from the Windows MIDI Services  
preview tools, which **does** receive messages from the same device at the same time.

* * *

## B) DETAILED STEPS TO REPRODUCE

1. Install the Hercules driver (`DJHERCULESMIX Products Series drivers` 2.HDJS.2026)  
and reboot.
2. Connect the DJControl Mix via USB and power it on.
3. Launch djay Pro.
4. Open **Settings \> MIDI**. `DJCONTROL MIX` appears and the built-in mapping  
`Hercules DJControl Mix` is assigned to it.
5. Open **Settings \> MIDI \> Learn / Mapping** and move any fader or press any pad.  
→ Nothing is detected.
6. Back in djay, press pads and move faders.  
→ No response.

* * *

## C) EXPECTED RESULTS

djay should respond to every control on the DJControl Mix using the built-in  
mapping — pads should trigger samples, faders should control channel and master  
volume, and the crossfader should sweep.

The same controller functions correctly in djay on iOS/Android over Bluetooth, and  
on Linux with Mixxx over USB.

* * *

## D) ACTUAL RESULTS

No control does anything. MIDI Learn detects nothing when a control is moved.

djay opens both MIDI ports successfully, which is visible in `mididiag`:

```auto
session_name : Windows.Devices.Midi client session
process_name : djayApp.exe
connection_count : 1
connection : port_flow=in port_number=0 port_name="DJCONTROL MIX"

session_name : Windows.Devices.Midi client session
process_name : djayApp.exe
connection_count : 1
connection : port_flow=out port_number=1 port_name="DJCONTROL MIX"

```

### The MIDI data does reach the application

`midi1monitor` (Microsoft’s reference tool, from  
`Windows.MIDI.Services.Tools.0.99.92-preview.11-x64`), with djay closed and the  
same device connected, **does** display incoming messages with channel and type  
when a control is moved:

- Port: `DJCONTROL MIX`, input, `MIDIU_KSA_1187256644396869675_0_0`
- Messages received on physical control movement

So the device delivers MIDI and the Windows MIDI stack surfaces it correctly. djay  
receives the ports. The messages arrive. djay does not act on them.

### The endpoint enumerates correctly in all three APIs

From `mididiag --include-winrt-midi1` — UMP, WinRT MIDI 1.0 and WinMM — with input  
and output, not muted, multi-client:

```auto
== enum_winrt_midi1_api_input_ports
winrt_midi1_port : name="DJCONTROL MIX"
 id=\\?\SWD#MMDEVAPI#MIDIU_KSA_1187256644396869675_0_0

== enum_ump_api_endpoints
name : DJCONTROL MIX
manufacturer : Guillemot Corporation
transport_code : KSA
native_data_format: midi1_bytestream
multi_client : true
muted : false
gtb : number=1 direction=source
gtb : number=2 direction=destination

```

### The built-in mapping is present, correct and assigned

`USBID` is `116961581` = `0x06F8B12D`, matching `VID_06F8&PID_B12D` exactly. It  
covers pads, faders, crossfader and monitoring:

```auto
mixer.crossfade
mixer.lineVolume1
mixer.lineVolume2
mixer.masterLevel
mixer.monitorLevel
sampler.turntable1.player1 .. player8 (the 8 performance pads)
transport.*, deck.*, effects.*, ...

```

And it is assigned to the live endpoint in djay’s preferences:

```auto
MidiEndpoint.\\?\SWD#MMDEVAPI#MIDIU_KSA_1187256644396869675_0_0...
  -> Hercules DJControl Mix.djayMidiMapping (wasBuiltIn = 1)

```

### Official troubleshooting guide applied in full

All Windows steps from the official guide were carried out before filing this.  
None changed the behaviour:

| Step | Result |
| --- | --- |
| 1. Install required drivers | Done — `HDJusbaudio` 6.1.1.0, WHCP-signed, `oem70.inf` |
| 2. Check Device Manager | Clean — `ProblemCode: 0`, no warning icons |
| 3. Try a different USB port | N/A — see note below |
| 4. Disable USB power saving | Already clear — no `SelectiveSuspend` set on either root hub |
| 5. Allow MIDI permissions | No `AppPrivacy` policy present, no MIDI `ConsentStore` entry blocking djay |
| 6. Update Windows | Fully patched, latest cumulative updates (16 Oct) |
| 7. Update controller firmware | Not applicable — see note below |
| 8. Non-class-compliant steps | Drivers installed before first connect, rebooted after install |

Also verified: the device is connected **directly** to a root hub with no  
intermediate USB hub, and is class-compliant, so the class-compliant vs.  
non-class-compliant distinction does not apply.

Notes on steps 3 and 7: this machine exposes only USB 3.0 root hubs (xHCI), with  
no dedicated USB 2.0 port. Firmware was not updated because the transport is  
already verified working end-to-end — `midi1monitor` receives messages over this  
same USB link, so speed, cable, power and firmware are not the failing element.

### Further checks that did not change the behaviour

- Stale duplicate MIDI endpoints from previous sessions were removed with  
`pnputil /remove-device`, and djay’s MIDI configuration was cleared and  
re-assigned.
- The issue persists with the Windows MIDI legacy API mode (`UseLegacyMidi = 1`,  
verified active via `midisrv` reporting `Stopped`) as well as the default  
`midisrv` mode.
- Hercules’ own control panel (`HDJSeries2CPL.exe`) **does** show incoming control  
activity. It reads the device through Hercules’ proprietary API  
(`hdjusbaudioapi_x64.dll`), not through the standard Windows MIDI API.
- Machine: Lenovo 82XD, Intel Core i7-13620H.

* * *

## QUESTIONS

1. The built-in mapping appears correct and assigned, yet no action fires. Is there  
a known issue with the DJControl Mix mapping on Windows specifically?
2. Hercules documents this controller as intended for djay on iOS/Android over  
Bluetooth LE, and states that USB mode on a computer is not intended for DJing.  
Is USB MIDI mode on Windows a supported configuration for this device?
3. Is there a way to confirm from within djay whether incoming MIDI messages are  
being processed at all, versus the mapping not matching?

## SUPPORTING DATA

Full `mididiag` output with the device connected and djay running is available on  
request.

* * *

_Filed by the user of the affected machine. Hardware and driver are vendor  
components; the Windows MIDI stack was independently verified working with  
Microsoft’s own tools._

---

<div class="post-metadata">

**Author:** ![Slak\_Jaw](https://community.algoriddim.com/user_avatar/community.algoriddim.com/slak_jaw/32/6517_2.png) [@Slak\_Jaw](https://community.algoriddim.com/u/Slak_Jaw)\
**Post date:** [October 17, 2026, 2:37pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/3 "2026-10-17T14:37:58Z")

</div>

Hi @fcojbb, welcome to the Community! Thanks for the thorough write-up.

Taking your questions in order:

**1. Known issue with the DJControl Mix mapping on Windows?**  
Not one I can find. Nothing in the recent release notes or open reports points at this mapping.

**2. Is USB on Windows a supported setup?**  
Yes. The DJControl Mix is on our supported list for Mac/PC, and Hercules’ own team has shown it working in djay on Windows 11 over USB. The “not meant for DJing in USB mode on a computer” wording I could find is in Hercules’ FAQ for the DJControl Mix _ **Ultra** _, not the original Mix.

**3. Can you tell from inside djay whether MIDI is arriving?**

MIDI Learn is that check. The MIDI configuration window lists the incoming note or CC as soon as you move a control. Since nothing shows up there, djay isn’t seeing the messages at all, so the built-in mapping isn’t what’s failing.

Two things to try, one at a time:

1. Update djay to 5.6.9 from the Microsoft Store (you’re on 5.6.7), then retest MIDI Learn.
2. If it still fails, run midi1monitor **with djay open** and move a fader. Your capture was taken with djay closed. If midi1monitor shows the messages while djay’s MIDI Learn shows nothing at the same moment, that’s the cleanest repro we can pass along.

Since the controller works with djay over Bluetooth on iOS/Android, that’s your best option for mixing until we get this sorted. Thanks!

---

<div class="post-metadata">

**Author:** ![fcojbb](https://community.algoriddim.com/letter_avatar_proxy/v4/letter/f/a6a055/32.png) [@fcojbb](https://community.algoriddim.com/u/fcojbb)\
**Post date:** [October 17, 2026, 8:11pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/4 "2026-10-17T20:11:55Z")

</div>

# Hercules DJControl Mix — no control responds on Windows, although MIDI is delivered and djay connects

**djay version:** 5.6.7040.0 (MSIX `59BEBC1A.djay`)  
**OS:** Windows 11 Home Single Language, 26H2, build 26300.9711  
**Controller:** Hercules DJControl Mix (`VID_06F8&PID_B12D`)  
**Driver:** `HDJusbaudio` 6.1.1.0 (`oem70.inf`), Guillemot Corporation, WHCP-signed  
**Machine:** Lenovo 82XD, Intel Core i7-13620H

* * *

Hi , thanks for the reply — both steps you suggested were carried out, and the  
simultaneous test produced a clear result. Answering your questions first, then  
the evidence.

**On the version — I am on the latest djay my Microsoft Store offers.** You  
mentioned 5.6.9; I was on 5.6.7 (`5.6.7040.0`). I uninstalled djay completely —  
package, profile data and shortcuts all removed — rebooted, and reinstalled from  
the Store. The Store served me `5.6.7040.0` again, the same build I already had.  
5.6.9 is not offered to my account or region, so I can’t move past that version.

I mention it because I want to be clear this wasn’t skipped: I tried to update as  
you suggested, and the update path is what came back.

**On the simultaneous test:** this is where it gets interesting. I ran  
`midi1monitor` with djay open at the same time, and moved a fader.  
`midi1monitor` received the messages. djay’s MIDI Learn showed nothing. Same  
session, same endpoint, same moment.

* * *

## A) SUMMARY OF ISSUE

djay Pro on Windows does not respond to any control on the Hercules DJControl  
Mix — not the pads, not the faders, not the crossfader. Nothing at all.

The controller, the Hercules driver and the Windows MIDI stack all work. djay sees  
the device, accepts the built-in mapping and opens both MIDI ports on the right  
endpoint. The MIDI arrives. djay just doesn’t act on it.

* * *

## B) STEPS TO REPRODUCE

1. Install `DJHERCULESMIX Products Series drivers` 2.HDJS.2026, reboot.
2. Connect the DJControl Mix via USB, power it on.
3. Launch djay Pro.
4. Open **Settings \> MIDI** — `DJCONTROL MIX` is listed and the built-in mapping  
`Hercules DJControl Mix` is assigned to it.
5. Open **Settings \> MIDI \> Learn / Mapping** and move a fader or press a pad.  
→ Nothing detected.
6. Back in djay, press pads and move faders.  
→ No response.

* * *

## C) EXPECTED RESULTS

djay should respond to every control using the built-in mapping — pads triggering  
samples, faders controlling channel and master volume, crossfader sweeping.

The same controller works in djay on iOS/Android over Bluetooth, and on Linux with  
Mixxx over USB.

* * *

## D) ACTUAL RESULTS

No control responds. MIDI Learn detects nothing.

### The simultaneous repro you asked for

Captured with djay and `midi1monitor` both attached to the same endpoint:

```auto
session_name : Cliente WinMM
process_name : midi1monitor.exe
connection_count : 1
connection : port_flow=in port_number=0 port_name="DJCONTROL MIX"

session_name : Windows.Devices.Midi client session
process_name : djayApp.exe
connection_count : 1
connection : port_flow=in port_number=0 port_name="DJCONTROL MIX"

session_name : Windows.Devices.Midi client session
process_name : djayApp.exe
connection_count : 1
connection : port_flow=out port_number=1 port_name="DJCONTROL MIX"

```

Both processes are on the same port at the same time. `midi1monitor` receives  
messages. djay connects but does not act.

### The detail that may matter most

Looking at those sessions closely: `midi1monitor` is connected through **WinMM** ,  
while djay connects through the modern **`Windows.Devices.Midi` (WinRT)** API.  
djay’s own WinMM client session reports `connection_count: 0` — it isn’t using  
WinMM at all.

One possibility is that data arriving on this KSA transport endpoint isn’t surfaced  
through the WinRT MIDI 1.0 API, which would explain why a WinMM client sees the  
messages and djay doesn’t. I couldn’t confirm it because djay doesn’t expose a  
setting to choose the MIDI API — so I’m presenting it as a lead rather than a  
conclusion.

### The endpoint is healthy

`mididiag --include-winrt-midi1` shows it enumerating in all three APIs (UMP, WinRT  
MIDI 1.0, WinMM), input and output, `multi_client: true`, `muted: false`:

```auto
== enum_winrt_midi1_api_input_ports
winrt_midi1_port : name="DJCONTROL MIX"
 id=\\?\SWD#MMDEVAPI#MIDIU_KSA_14561102149308801208_0_0

== enum_ump_api_endpoints
name : DJCONTROL MIX
manufacturer : Guillemot Corporation
transport_code : KSA
native_data_format: midi1_bytestream
multi_client : true
muted : false
gtb : number=1 direction=source
gtb : number=2 direction=destination

```

### The built-in mapping looks correct

Its `USBID` is `116961581` = `0x06F8B12D`, matching `VID_06F8&PID_B12D` exactly, and  
it covers pads, faders, crossfader and monitoring:

```auto
mixer.crossfade
mixer.lineVolume1
mixer.lineVolume2
mixer.masterLevel
mixer.monitorLevel
sampler.turntable1.player1 .. player8 (the 8 performance pads)
transport.*, deck.*, effects.*, ...

```

It’s assigned to the live endpoint in djay’s preferences with `wasBuiltIn = 1`.  
Which matches what you said — since MIDI Learn shows nothing, the mapping isn’t  
what’s failing.

### Your troubleshooting guide, applied in full

Every Windows step from the official guide was done before filing this:

| Step | Result |
| --- | --- |
| 1. Install required drivers | Done — `HDJusbaudio` 6.1.1.0, WHCP-signed |
| 2. Check Device Manager | Clean — `ProblemCode: 0`, no warning icons |
| 3. Try a different USB port | Done — moved from port 1 to port 4, same result |
| 4. Disable USB power saving | Already clear — no `SelectiveSuspend` on either root hub |
| 5. Allow MIDI permissions | No `AppPrivacy` policy, no MIDI `ConsentStore` entry blocking djay |
| 6. Update Windows | Fully patched, latest cumulative updates (16 Oct) |
| 7. Update controller firmware | Not applied — see note |
| 8. Non-class-compliant steps | Drivers installed before first connect, rebooted after |

Also confirmed: connected **directly** to a root hub with no intermediate USB hub,  
and the device is class-compliant, so that distinction doesn’t apply here.

On step 7 — firmware wasn’t touched because the transport is already verified  
working end to end: `midi1monitor` receives messages over this same USB link, so  
speed, cable, power and firmware aren’t the failing element. Happy to apply it if  
you think it’s worth ruling out.

### Other things ruled out

- **Stale MIDI endpoints.** Duplicate endpoints from previous sessions were removed  
with `pnputil /remove-device`, and djay’s MIDI configuration was cleared and  
re-assigned. Endpoint is now a single clean one (`MIDIU_KSA_14561102149308801208`).
- **Clean reinstall.** djay fully uninstalled, profile data removed, rebooted,  
reinstalled. Not a configuration corruption issue.
- **Both MIDI API modes.** Same result with the legacy mode (`UseLegacyMidi = 1`,  
verified active via `midisrv` reporting `Stopped`) and with the default `midisrv`.
- **Hercules’ own control panel works.** `HDJSeries2CPL.exe` does show incoming  
control activity — but it reads the device through Hercules’ proprietary API  
(`hdjusbaudioapi_x64.dll`), not through the standard Windows MIDI API.
- **USB cable.** Tested with two different cables. One behaved oddly: djay  
registered sessions but couldn’t attach (`connection_count: 0`) and blocked WinMM  
clients from opening the port. After a reboot on the other cable it attached  
normally. **The functional symptom was identical either way** — no response to any  
control. Mentioning it only since cable behaviour is a known variable on this  
line of controllers.

* * *

## QUESTIONS

1. Given that djay connects over WinRT while a WinMM client receives the data on  
the same endpoint — is there a known issue with the WinRT MIDI path on this kind  
of controller? And is there a way to make djay use WinMM on Windows instead?

2. On your question about supported configurations: USB MIDI on Windows is listed  
as supported for this model, and it works over Bluetooth. Is there any  
difference between how the Mix and the Mix Ultra are handled here that might  
explain this?

3. Is there a way to confirm from inside djay whether incoming MIDI is being  
processed at all, separately from whether the mapping matches?

* * *

> `mididiag` output with the device connected and djay running alongside  
> `midi1monitor` is:
> 
> == enum\_winmm\_midi1\_api\_output\_ports  
> endpoint\_count : 2  
> winmm\_port : index=0 technology=software\_synth mid=1 pid=27 version=1.0 name=“Microsoft GS Wavetable Synth”  
> winmm\_port : index=1 technology=port mid=1 pid=102 version=10.0 sdk\_number=1 name=“DJCONTROL MIX”  
> dev\_caps\_error\_count : 0
> 
> == transport\_loopback  
> feedback\_protection\_available : false
> 
> == endpoint\_customizations  
> customization\_count : 0  
> orphaned\_customization\_count : 0
> 
> == enum\_sessions  
> session\_count : 7
> 
> session\_name : MIDI 2.0 Protocol Manager  
> process\_name : MidiSrv.exe  
> process\_id : 4032  
> session\_owner : service  
> session\_start\_time : 2026-10-17 16:41:45  
> connection\_count : 0
> 
> session\_name : Cliente WinMM  
> process\_name : HDJSeries2CPL.exe  
> process\_id : 11672  
> session\_start\_time : 2026-10-17 16:41:57  
> connection\_count : 0
> 
> session\_name : Cliente WinMM  
> process\_name : midi1monitor.exe  
> process\_id : 2264  
> session\_start\_time : 2026-10-17 16:48:37  
> connection\_count : 1  
> connection : instances=1 port\_flow=in port\_number=0 port\_name=“DJCONTROL MIX” id=\?\swd#mmdevapi#midiu\_ksa\_14561102149308801208\_0\_0#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b}
> 
> session\_name : Cliente WinMM  
> process\_name : djayApp.exe  
> process\_id : 6752  
> session\_start\_time : 2026-10-17 16:50:05  
> connection\_count : 0
> 
> session\_name : Windows.Devices.Midi client session  
> process\_name : djayApp.exe  
> process\_id : 6752  
> session\_start\_time : 2026-10-17 16:50:05  
> connection\_count : 1  
> connection : instances=1 port\_flow=in port\_number=0 port\_name=“DJCONTROL MIX” id=\?\swd#mmdevapi#midiu\_ksa\_14561102149308801208\_0\_0#{504be32c-ccf6-4d2c-b73f-6f8b3747e22b}
> 
> session\_name : Windows.Devices.Midi client session  
> process\_name : djayApp.exe  
> process\_id : 6752  
> session\_start\_time : 2026-10-17 16:50:05  
> connection\_count : 1  
> connection : instances=1 port\_flow=out port\_number=1 port\_name=“DJCONTROL MIX” id=\?\swd#mmdevapi#midiu\_ksa\_14561102149308801208\_1\_0#{6dc23320-ab33-4ce4-80d4-bbb3ebbf2814}
> 
> session\_name : Cliente WinMM  
> process\_name : mididiag.exe  
> process\_id : 13224  
> session\_owner : this\_report  
> session\_start\_time : 2026-10-17 16:50:23  
> connection\_count : 0
> 
> == ping\_test  
> ping\_attempt\_count : 10  
> ping\_return\_count : 10  
> round\_trip\_total\_ticks : 3724  
> round\_trip\_average\_ticks : 372
> 
> == connection\_timing  
> session\_create\_ms : 0  
> diagnostics\_loopback\_open\_ms : 15  
> diagnostics\_loopback\_opened : true
> 
> == findings  
> finding\_count : 1  
> finding : id=config\_not\_registered text=“No MIDI configuration file is registered, so settings such as custom names, loopbacks and network hosts can’t be saved. Opening the MIDI Settings app once sets one up.”
> 
> == section\_timing  
> section : name=header elapsed\_ms=0  
> section : name=os elapsed\_ms=13  
> section : name=processor\_env elapsed\_ms=0  
> section : name=native\_system\_info elapsed\_ms=0  
> section : name=dev\_mode elapsed\_ms=0  
> section : name=api\_mode elapsed\_ms=2  
> section : name=component\_versions elapsed\_ms=1  
> section : name=service\_status elapsed\_ms=63  
> section : name=service\_history elapsed\_ms=20  
> section : name=reg\_drivers32 elapsed\_ms=0  
> section : name=reg\_drivers32wow elapsed\_ms=0  
> section : name=enum\_registry elapsed\_ms=2  
> section : name=device\_nodes elapsed\_ms=3  
> section : name=network elapsed\_ms=20  
> section : name=mdns elapsed\_ms=49  
> section : name=network\_history elapsed\_ms=51  
> section : name=service\_response elapsed\_ms=2  
> section : name=midi\_clock elapsed\_ms=0  
> section : name=enum\_transports elapsed\_ms=23  
> section : name=enum\_ump\_api\_endpoints elapsed\_ms=34  
> section : name=enum\_winmm\_midi1\_api\_input\_ports elapsed\_ms=15  
> section : name=enum\_winmm\_midi1\_api\_output\_ports elapsed\_ms=96  
> section : name=transport\_loopback elapsed\_ms=41  
> section : name=endpoint\_customizations elapsed\_ms=24  
> section : name=enum\_sessions elapsed\_ms=0  
> section : name=ping\_test elapsed\_ms=27  
> section : name=connection\_timing elapsed\_ms=27  
> total\_elapsed\_ms : 527
> 
> == successful\_run
> 
> == end\_of\_file

---

<div class="post-metadata">

**Author:** ![Slak\_Jaw](https://community.algoriddim.com/user_avatar/community.algoriddim.com/slak_jaw/32/6517_2.png) [@Slak\_Jaw](https://community.algoriddim.com/u/Slak_Jaw)\
**Post date:** [October 17, 2026, 8:41pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/5 "2026-10-17T20:41:45Z")

</div>

Thanks for the additional info @fcojbb. Can you please open the djay Settings, scroll to the bottom and share a screenshot of the version number you see there? Sounds like you might be reporting the Store package build number instead of the djay version number. Thanks.

---

<div class="post-metadata">

**Author:** ![Slak\_Jaw](https://community.algoriddim.com/user_avatar/community.algoriddim.com/slak_jaw/32/6517_2.png) [@Slak\_Jaw](https://community.algoriddim.com/u/Slak_Jaw)\
**Post date:** [October 17, 2026, 8:59pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/6 "2026-10-17T20:59:07Z")

</div>

@fcojbb thanks for running both tests so carefully, and for doing a clean reinstall on top of it.

This lines up closely with a known Windows MIDI Services bug from the Windows 11 25H2 rollout earlier this year. WinRT MIDI 1.0 delivered messages with timestamps far in the future, so apps on that API, djay included, never acted on them, while WinMM apps worked fine. Microsoft has since rolled a fix into Windows, but your capture suggests something similar may still be happening on 26H2. There’s no setting in djay for choosing the MIDI API.

Previous topic for reference: [Windows 11 25H2: MIDI Connectivity Issues (FLX4 & SC LIVE 4)](https://community.algoriddim.com/t/windows-11-25h2-midi-connectivity-issues-flx4-sc-live-4/41530)

**Next test**  
Microsoft’s standalone patch for that bug fixed it for several djay users on 25H2:

> **[Release (old) WinRT MIDI 1.0 Timestamp Fix · microsoft/MIDI](https://github.com/microsoft/MIDI/releases/tag/winrt-midi1-timestamp-fix)**
>
> 2026-10-01 old release artifacts removed to avoid customer / developer confusion
> 2026-03-18 An updated version with the correct port-relative timestamps is attached below. The previous one has been...

It replaces Windows.Devices.Midi.dll in System32 and saves the original as a .bak, so it’s easy to undo (the steps are on that page). Since you’re on 26H2, the patch is older than your current system file, so please treat it as a test and roll back if nothing changes.

If you’d rather not touch System32, a side-by-side capture with legacy mode active would also help. If midi1monitor still receives and djay still doesn’t with midisrv stopped, that points away from this bug.

Two quick questions to round things out:

1. Has this controller ever worked in djay on this PC, for example before 26H2?
2. Was djay already failing before you installed the Windows MIDI Services preview tools?

---

<div class="post-metadata">

**Author:** ![fcojbb](https://community.algoriddim.com/letter_avatar_proxy/v4/letter/f/a6a055/32.png) [@fcojbb](https://community.algoriddim.com/u/fcojbb)\
**Post date:** [October 18, 2026, 2:12pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/7 "2026-10-18T14:12:25Z")

</div>

Hi Slak Jaw, following up with the two results you asked for, plus one thing you’ll want to know.

**Did the controller ever work in djay on this PC?** Yes — on the earlier Windows 11  
build, same machine, controller, Hercules driver and cable. Regression from the 26H2  
rollout on my side.

**Was djay already failing before the preview tools?** Yes. I installed them afterwards,  
only to compare against `midi1monitor`.

## The legacy capture points away from the WinRT bug

I ran the side-by-side test you suggested. With `UseLegacyMidi = 1`, rebooted, mode  
verified active (`midisrv` reporting `Stopped`, no WinRT MIDI 1.0 in the path):

- `midi1monitor` still **receives** messages
- djay still **does not respond**

You wrote that this points away from the WinRT bug. That’s what I got — the symptom is  
identical with WinRT completely out of the picture. In legacy mode the ports are plain  
WinMM and both enumerate fine, but one WinMM client reads the input port while djay,  
which also registers as a WinMM client, doesn’t act on it.

## What djay’s own log shows

With `QT_LOGGING_RULES=*.debug=true` and `QT_WIN_DEBUG_CONSOLE=new`, the only MIDI line  
djay ever emits is:

```auto
[DJCore] Added MIDI device: DJCONTROL MIX (built-in, USB ID: 0x6F8B12D)

```

It detects the controller and gets the USB ID right, but with debug forced on and every  
fader and pad moved, **no incoming message is ever logged.** Same in both API modes.

## The patch is no longer downloadable

`winrt-midi1-timestamp-fix` returns `"assets": []` — all older releases on that repo are  
tagged `(old)`, _“artifacts removed to avoid customer / developer confusion”_ (2026-10-01).  
Instructions still on the page, file gone. Anyone on 26H2 waiting on it has nothing to  
grab.

## Control

Mixxx — independent open-source DJ software, unrelated to Algoriddim — drives the same  
controller correctly on this same machine, same driver, same cable. Hardware, driver and  
the Windows MIDI stack are all confirmed working.

Win11 26H2 build 26300.9711 · djay Pro 5.6.7040.0 · driver `HDJusbaudio` 6.1.1.0 (WHCP) ·  
Hercules DJControl Mix `VID_06F8&PID_B12D`

## Questions

1. If it fails in legacy mode too, does that point at something other than the WinRT  
timestamps? I’d rather not keep working my own setup if the fault is on your side.

2. Is there a djay build or setting that reads MIDI via WinMM on Windows?

3. If the WinRT timestamp bug is the cause, is Microsoft tracking whether it’s fixed in  
26H2? The release notes name djay Pro specifically.

I’m on Bluetooth and working around it for now. Happy to test anything else, or send  
the full `mididiag` output for either mode.

* * *

fcojbb

---

<div class="post-metadata">

**Author:** ![Slak\_Jaw](https://community.algoriddim.com/user_avatar/community.algoriddim.com/slak_jaw/32/6517_2.png) [@Slak\_Jaw](https://community.algoriddim.com/u/Slak_Jaw)\
**Post date:** [October 18, 2026, 2:49pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/8 "2026-10-18T14:49:38Z")

</div>

Thanks @fcojbb, this is exactly the data we needed, and the Mixxx test on the same machine is especially useful.

Regarding your additional questions:

**1. Does the legacy-mode failure point somewhere else?**  
Yes. Since it fails the same way with the new MIDI stack switched off, it points away from the timestamp bug. That together with Mixxx working on the same setup and djay’s log never recording an incoming message, points at something on our side I think. I’ve escalated it to our engineering team.

**2. A djay build or setting that reads MIDI via WinMM?**  
Not that I’m aware of, and there’s no setting for it.

**3. Is Microsoft tracking this for 26H2?**  
I can’t speak for Microsoft. Their published known-issues list only covers 24H2, 25H2 and 26H1. Given your legacy-mode result, though, their timestamp bug no longer looks like the cause here.

Yes, could you please send me the **full mididiag output** for both modes in a **DM**? It contains system details, so it’s better kept out of the public thread.

 ![IMG_2356](https://community-assets.algoriddim.com/original/3X/9/3/93408223a84326cd36a12763cf7d4f03dde684b7.jpeg)

Glad Bluetooth is working for you in the meantime. I’ll post here as soon as I have news.

---

<div class="post-metadata">

**Author:** ![Slak\_Jaw](https://community.algoriddim.com/user_avatar/community.algoriddim.com/slak_jaw/32/6517_2.png) [@Slak\_Jaw](https://community.algoriddim.com/u/Slak_Jaw)\
**Post date:** [October 18, 2026, 3:30pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/9 "2026-10-18T15:30:52Z")

</div>

Hi again @fcojbb, in addition to the **full mididiag output via DM** , could you please also provide the following so I have a complete report for our engineering team?

1. A screenshot of the djay version at the bottom of the main djay Settings menu. It should be 5.6.9.
2. The last Windows build where it worked, and whether you updated djay also around the same time as 26H2.
3. A short screen recording with djay’s MIDI mapping window and midi1monitor side by side while moving a fader, and pressing a button in both MIDI modes.

Thanks!

---

<div class="post-metadata">

**Author:** ![Slak\_Jaw](https://community.algoriddim.com/user_avatar/community.algoriddim.com/slak_jaw/32/6517_2.png) [@Slak\_Jaw](https://community.algoriddim.com/u/Slak_Jaw)\
**Post date:** [October 24, 2026, 3:12pm UTC](https://community.algoriddim.com/t/hercules-djcontrol-mix-no-midi-response-windows/43539/11 "2026-10-24T15:12:19Z")

</div>

Hello! It’s been a week since my last reply. I’m going to consider this topic completed for now so I can focus on others. However, please feel free to respond and we can definitely revisit this. Thanks!