Hercules DJControl Mix: No MIDI Response (Windows)

fcojbb · October 17, 2026, 1:52pm

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

Install the Hercules driver (DJHERCULESMIX Products Series drivers 2.HDJS.2026)
and reboot.
Connect the DJControl Mix via USB and power it on.
Launch djay Pro.
Open Settings > MIDI. DJCONTROL MIX appears and the built-in mapping
Hercules DJControl Mix is assigned to it.
Open Settings > MIDI > Learn / Mapping and move any fader or press any pad.
→ Nothing is detected.
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:

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:

== 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:

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:

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

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?
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?
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.

Slak_Jaw · October 17, 2026, 2:37pm

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:

Update djay to 5.6.9 from the Microsoft Store (you’re on 5.6.7), then retest MIDI Learn.
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!

fcojbb · October 17, 2026, 8:11pm

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

Install DJHERCULESMIX Products Series drivers 2.HDJS.2026, reboot.
Connect the DJControl Mix via USB, power it on.
Launch djay Pro.
Open Settings > MIDI — DJCONTROL MIX is listed and the built-in mapping
Hercules DJControl Mix is assigned to it.
Open Settings > MIDI > Learn / Mapping and move a fader or press a pad.
→ Nothing detected.
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:

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:

== 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:

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

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?
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?
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

Slak_Jaw · October 17, 2026, 8:41pm

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.

Slak_Jaw · October 17, 2026, 8:59pm

@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)

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

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:

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

fcojbb · October 18, 2026, 2:12pm

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:

[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

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.
Is there a djay build or setting that reads MIDI via WinMM on Windows?
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

Slak_Jaw · October 18, 2026, 2:49pm

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.

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

Slak_Jaw · October 18, 2026, 3:30pm

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?

A screenshot of the djay version at the bottom of the main djay Settings menu. It should be 5.6.9.
The last Windows build where it worked, and whether you updated djay also around the same time as 26H2.
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!

Slak_Jaw · October 24, 2026, 3:12pm

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!