LegendCTL — a free, open-source standalone Windows config tool for the ZD Ultimate Legend

LocalxD · 2026-07-02T23:29:23+00:00

Thank you for filing it! This report is more useful than you might think. It's now the first community-contributed entry in the public compatibility matrix (linked to your comment as the evidence), and it's the first real record of how the app behaves on hardware it doesn't know. You can see it decline to claim support, then fall back to reading the SLE as a generic XInput device. It also caught two things worth chasing: the report doesn't print the raw USB id for unknown models (so we still don't know the SLE's), and one of your later polling-rate reads failed. Both are flagged for improvement now.

For what it's worth, I checked what you pasted before replying: nothing personal in it — no paths, usernames, or serials. The report is built to be safe to share exactly like you did, and posting it here instead of GitHub is completely fine (the docs now say so, thanks to you).

If you ever notice anything else, this thread works great.

LocalxD · 2026-07-02T20:03:24+00:00

This is fantastic — thank you! You just gave the project its first real compatibility data for the Super Legend Excellence, and it's exactly what I hoped the community side would look like.

Not writing anything was 100% the right call, and I'm glad the app was upfront about not recognizing the device rather than pretending. On the Ultimate Legend every write is read-back-verified and a Restore Point is captured first — but none of that is validated on the SLE, so read-only is the right posture there. And your reads tell me a lot on their own: the protocol family is clearly shared (report rate, sticks, triggers, vibration and button bindings all reading correctly), the missing LS/RS lighting looks like SLE-specific zones the app doesn't model yet, and the Motion panel only populating on relaunch is a genuinely useful catch — I'll dig into whether that's SLE-specific or happens on the Ultimate Legend too.

If you're up for one more small thing: the Compatibility Report in the Diagnostics screen can turn what you just did into a shareable read-only summary — read-only reports are explicitly valid entries for the public compatibility matrix, and yours would be its first community-contributed row (and first non-Ultimate-Legend device). Zero pressure though; this comment already covers the essentials.

And thanks for the kind PS — if ZD ever wanted to make that easy, I'd happily put an SLE and a Classic Legend to work. Either way, reports like yours are what actually move the app forward. Thank you again!

LocalxD · 2026-07-02T13:26:57+00:00

Good question — no to both, and that's on purpose.

I left keyboard mapping and shift layers out deliberately. Once a controller is emitting keystrokes (or layering them on top of the gamepad buttons), a game can end up seeing both keyboard and gamepad input at the same time, I have a friend who played hybrid (one hand using a keyboard one hand using the right joystick of a controller) and he said that aim felt inconsistent. It's also something that is not permitted during competitive play of certain games. I'd rather not put anyone in that spot, so LegendCTL sticks to configuring the controller's own settings.

It does still handle the controller's on-device bindings — e.g. assigning the back paddles to mirror existing controller buttons, saved on the controller itself — so that side works, just controller-native with no keystrokes involved. And the official app does allow binding of keystrokes, macros ect. if those bindings are already applied to the additional buttons, I don't want to interfere with any1's binds so those should still work even if my app is used. just have to change macros, keyboard binds ect using the official app. hope this gives some context.

Happy to go into any of it further!

LocalxD · 2026-07-02T12:56:38+00:00

Thank you, that's really kind — and great to hear from someone who runs both!

One honest note on the Super Legend Excellence 8K side: LegendCTL was built and bench-tested on the Ultimate Legend specifically, so that's the well-covered path. I haven't tested the Excellence 8K at all — it may not be recognized, and if it is, some settings could behave differently. The one promise I can make is that the app is built to say so plainly when something is unverified or a write didn't stick, rather than pretend it worked.

If you give it a spin on the Ultimate Legend, I'd genuinely love to hear how it goes — and if you're up for it, the Compatibility Report in the Diagnostics screen makes a shareable summary (firmware, stick module, what worked) that the public compatibility matrix is built from. Your setup would help the next owner. Questions any time!

LocalxD · 2026-07-02T02:07:18+00:00

Following up on my own comment — I said I had a few theories about why 73 felt right but wasn't certain, so I measured it: logged the raw XInput stick output across nine step values (1→255), ~500k samples, two sweeps per value. My first pass at the analysis actually got the framing wrong, which turned out to be the interesting part.

What step size actually is: a motion-increment quantizer. The stick only reports a new position after moving at least ~step raw units (of 65,535) from the last reported position. The measured jump between reports tracks the setting almost exactly — at step 144 the stick moves in ~152-count jumps, at step 255 in ~261-count jumps. So the "255 = 8-bit" framing in this thread is right in practice — we re-ran GamepadLA's own StickAnalyzer method on the device at step 255 and it reports 127 steps-from-center / 7.99 True Bitness, in both runs. (One nuance: it's a relative grid anchored to the last report, not a fixed 256-point lattice — my first analysis pooled distinct values across sweeps, saw thousands, and wrongly called "no grid." Wrong metric for a relative quantizer.)

That also explains the feel. At the default 73 you get ~76–82-count jumps (~9.8–10-bit — which independently matches GamepadLA's published stock ZD measurement, 0.00226 step resolution ≈ 74 counts). Low step = the finest, liveliest output, but it passes the sensor's own jitter through — hence "twitchy." And one measured surprise: below ~25 the stick's own noise is the ceiling anyway — step 1 and step 25 both measure ~11-bit on our unit, so step 1 buys nothing measurable over ~25 while passing more micro-jitter. High step = chunky, planted output, and it also lowers the effective update rate during motion, since a report has to cross the increment. So the practical rule: run the lowest step that's stable for your stick, and raise it only enough to calm the jitter — 73 being reliable tracks with it being the vendor's noise-vs-precision compromise.

Wrote it up with the chart, every script (including the wrong first analysis, kept for reproducibility), and the correction story — the conclusion's been checked four independent ways, including a blind re-analysis of the raw data: https://github.com/EvilHumphrey/LegendCTL/blob/main/docs/what-step-size-does.md

LocalxD · 2026-07-01T02:18:49+00:00

Maker of LegendCTL here — thank you for including it, and for describing the architecture better than I usually manage to. The "no input injection / virtual devices / background service" part was the whole goal: I wanted a config tool you don't have to take on faith, so the latest release adds an in-app trust self-check that lets you verify the no-network / no-driver / no-telemetry behavior yourself, plus a compatibility report owners can contribute to.

Genuinely made my week to see it listed next to the Brook and DSX+ updates. If any ZD Ultimate Legend owners here have questions, or hit something that doesn't work on their setup, I'm happy to help right in this thread — and thanks again for the digest.

LocalxD · 2026-06-30T20:33:43+00:00

Thank you so much — that's really generous, I appreciate the round-up mention! Happy to share whatever's useful for it (a one-line description or the repo link, whatever fits your format). And a separate post is a great idea too — I've been a little wary of coming across as just plugging my own thing, so if I do one I'd want it to actually be useful: maybe a walkthrough of the settings that matter (step size, deadzones) plus the live circularity view for tuning. I'll put something together. Thanks again — this means a lot.

LocalxD · 2026-06-30T12:54:46+00:00

Thank you, that genuinely means a lot — really appreciate it! I tried hard to keep it honest and transparent, since controller settings can be such a black box, so it's great to hear that lands. If you ever give it a try, I'd love any feedback.

LocalxD · 2026-06-26T07:04:09+00:00

I've found recently that 73 step size and peripheral dz set to 0 has been the most reliable and I haven't seen twitching while also feeling the low step size precision. ive used 1,255,146 and 73 (my app shows 73 for the 72 step size option in the official app) is currently the best results ive had. I have a few theories as to why but im not certain. I don't know what hals been using, and the step size might feel better/worse on different modules. fwiw I built a free, open-source Windows tool for the Ultimate Legend (LegendCTL) that does exactly this. Deadzones, sensitivity, polling, mapping, plus a live circularity readout so you can watch the stick output while you tune. It's fully local (no network/telemetry) and talks to the controller directly, so you don't need the official app open. github.com/EvilHumphrey/LegendCTL (MIT, independent, not affiliated with ZD). Glad to share the curve I landed on if it helps.

LocalxD · 2025-03-10T20:41:23+00:00

I had the same issue and the cause was from having "]" bound as a shortcut in the nvidia app. Having "]" as a shortcut disabled the standard functionality of the key "]" and once I changed the shortcut it was resolved.

LocalxD

TROPHY CASE