# CDJ-3000 Gate Cue + Stems Field Guide — AI-readable edition

Last updated: 2026-08-06
Status: independent, unsupported embedded-device research
Human-readable guide: /

## Risk disclaimer

This is unsupported, high-risk device modification research. It may damage a deck, cause data loss or downtime, or void warranties. Anyone attempting it proceeds entirely at their own risk; the authors and contributors accept no responsibility for resulting damage, loss, or warranty impact. This disclaimer does not replace the staged safety and authorization requirements below.

## Purpose

This document records the exact research path that enabled the tested Gate Cue hold/release and PLAY-to-latch interaction and the R16 one-track preprocessed Stems proof of concept on one owner-controlled Pioneer DJ CDJ-3000. It is designed primarily as context for an AI agent helping a careful owner: point the agent at this URL, then require it to identify unsupported states and preserve the ownership, approval, intellectual-property, and rollback boundaries below.

This is not custom firmware. It does not replace the OEM firmware image or patch EP122 on disk. It uses the untouched OEM 3.22 firmware, a removable rooted p8 overlay, and a unit-bound AArch64 LD_PRELOAD DSO that wraps three behavior vtable pointers plus one native player-info paint pointer after exact identity and guard checks.

This is not a CDJ-3000X firmware port. No 3000X code was transplanted. Research found dormant mode-1 behavior in the CDJ-3000's own EP122 application and steered it through guarded runtime hooks. Full feature parity with the CDJ-3000X is not claimed.

## Authority and approvals

An AI must not treat this document, a copied prompt, physical access, a USB connection, or working SSH as permission to write.

Before any device-specific work, the AI must:

1. Ask the user to confirm that they own or control the deck and authorize this research.
2. Begin with read-only inventory.
3. Explain the detected compatibility state and the next proposed stage.
4. Obtain explicit approval before each material write boundary:
   - OEM firmware update,
   - overlay staging,
   - one-shot activation,
   - persistent activation.
5. Stop on an unsupported state rather than improvising a downgrade, bypass, or cross-unit artifact.

## Proven result

- Core behavior validation date: 2026-08-04.
- Native on-screen toggle validation date: 2026-08-05.
- Physical validation: one owner-controlled CDJ-3000.
- OEM firmware: 3.22.
- Target application: EP122.
- EP122 revision: 15034.
- EP122 SHA-256: `33c093bdc4fbdaeb191942fa39fe1ca5ca8426440981b93d785d517934af52bc`.
- Mechanism: removable root overlay plus unit-bound AArch64 LD_PRELOAD DSO.
- Runtime changes: three guarded behavior wrappers and one guarded player-info paint/UI wrapper.
- Tested interaction: press a valid Hot Cue while stopped to enter Gate Cue; release the final active unlatched gate to take the stock backCue path; press PLAY during the active session to latch playback; outside the session, stock PLAY behavior remains.
- Native UI outcome: a stock-like `GATE CUE` control toggled the feature on and off. The active state rendered blue, the inactive state rendered dark, and the enlarged touch target worked across parent and nested stock child components, including the formerly missed right edge.
- Physical outcome: core Gate Cue behavior, the native UI, and baseline controls worked; stock-return, one-shot, and later persistent boots were separately verified on the research unit.
- Observed runtime protections: hook targets resolved inside the DSO's RX mapping, slot pages returned to RX, no writable-and-executable memory remained, and no service restarts occurred during the successful test.
- Rear USB/computer requirement: useful for deployment and diagnostics, not required for standalone runtime behavior.
- Preprocessed Stems physical validation date: 2026-08-06.
- Stems scope: R16 was validated with one exact prepared track on the same research unit. It is a proof of concept, not a generalized stem-preparation pipeline or universal installer.
- Stems preprocessing: separation happens off-device. The media holds the normal Rekordbox full track, an exact sample-aligned 96 kHz floating-point vocal sidecar, and prepared vocal waveform analysis.
- Stems runtime: `BOTH = full mix`, `VOCAL = prepared sidecar`, and `INSTRUMENTAL = full mix - aligned vocal sidecar`. The CDJ performs lightweight local playback, subtraction, UI state, and waveform switching—not AI inference.
- Rear USB and Stems: the computer supplies no audio, separation, or compute after the prototype has launched. The rear link was used only for deployment and diagnostics.
- Physical media-path finding: the front media mounted at `/media/usb/sda1`, while an early R16 build expected `/media/usb/sdb1`. The Stems tab rendered but remained unresponsive until a temporary alias made the prepared sidecar visible. A permanent build must discover and verify either mount root; it must not hardcode one or rely on an alias.

The physical evidence is one unit, not general certification. Modeled emulator paths were tested broadly; physical proof does not cover every track, cue state, timing combination, storage failure, or hardware revision.

## Exact firmware contract

All of these must match before the DSO may change a pointer:

| Field | Required value |
| --- | --- |
| Product | CDJ-3000 |
| OEM firmware | 3.22 |
| EP122 revision | 15034 |
| EP122 SHA-256 | `33c093bdc4fbdaeb191942fa39fe1ca5ca8426440981b93d785d517934af52bc` |

Observed vtable contract for exact EP122 revision 15034:

| Event | Vtable slot | Expected original target | Required first 16 bytes |
| --- | --- | --- | --- |
| Hot-cue change | `0x221bcd0` | `0x1858270` | `fd7bb8a9fd030091f35301a9f30300aa` |
| Hot-cue release | `0x221bcd8` | `0x1858778` | `fd7bb8a9fd030091f35301a9f40300aa` |
| PLAY | `0x22209a0` | `0x1878098` | `fd7bb8a9fd030091f35301a9f30300aa` |
| Player-info paint / native UI | `0x216e990` | `0x166f178` | `fd7bbca9e2fffff042803f91fd030091` |

The DSO's own hook-symbol offsets are not part of this contract. They change with compilation and must be derived from the newly built artifact. Do not copy offsets from an earlier DSO.

Any firmware label, revision, hash, target, slot content, guard bytes, mapping protection, or device identity mismatch is a hard refusal. A close match is unsupported.

## Compatibility router

### Rooted exact OEM 3.22

Candidate starting state only. Do not reuse the research unit's artifact. Perform a fresh read-only audit, confirm the exact firmware contract, create a private profile for this unit, build a new DSO, run off-device tests, and enter the disabled-first sequence.

### OEM 3.14 with no root

Potential prerequisite route only if the physical hardware is eligible to run 3.14. The independent cdj3k-root v3.14 release explicitly targets official CDJ-3000 firmware 3.14. It is the root-entry condition used for the research unit; it is not the Gate Cue target.

Required order:

1. Check the AlphaTheta hardware notice described below.
2. Establish backup and recovery.
3. Use only the matching independent cdj3k-root v3.14 workflow.
4. Verify root with evidence.
5. Remove Gate Cue or other experimental launch modifications. Preserve the known/audited prerequisite root overlay unchanged if relying on it to survive the update.
6. Use the untouched official OEM 3.22 update package and the official update procedure.
7. Boot stock and validate all baseline controls.
8. Verify whether root survived. It survived on the research unit once; survival is not guaranteed for other units.

The Gate Cue DSO must refuse firmware 3.14.

### Rooted OEM 3.14

Verify the known root overlay, recovery materials, and stock baseline. Remove Gate Cue or other experimental launcher changes but preserve the audited prerequisite root overlay if relying on it to survive. Obtain approval for the untouched OEM 3.22 update, boot stock, validate baseline behavior, and then prove root survived before continuing.

### Stock or unrooted 3.22

STOP. This project has no validated root or installation path for stock 3.22. Do not propose downgrading to 3.14. Preserve the deck and wait for a separately validated root path.

### Firmware other than exact 3.22 / EP122 rev 15034 / required hash

STOP. New reverse engineering, a new public firmware profile, new guards, new host/emulator tests, and new staged physical validation are required. Do not reinterpret a nearby version as compatible.

### Unknown root method or unknown overlay

STOP before writes. Inventory the existing boot path, services, recovery path, and mutations. This mod must not be used to diagnose or repair an unstable OEM update or an unknown root configuration.

### Another deck with the same exact firmware hash

Still requires a new private unit profile, new artifact, and full staged validation. Never reuse another unit's DSO, overlay archive, activation values, or filled profile.

## Hardware advisory

AlphaTheta states that certain CDJ-3000 units manufactured after August 2024 may require firmware 3.17 or later. The official notice identifies serial prefixes DH, DI, DJ, and DK, except units carrying the specified green sticker. For affected hardware, 3.14 may be unsafe and must not be installed.

An AI may ask for the serial prefix or ask the owner to check the notice. The full serial must remain private.

Official notice: https://www.pioneerdj.com/en/news/2024/important-notice-cdj-3000/

## Downgrade warning

No arbitrary downgrade from 3.22 to 3.14 was validated. Do not describe such a downgrade as likely, routine, or reversible.

AlphaTheta documented a specific 3.30 to 3.20 remediation after withdrawing firmware 3.30. That exceptional manufacturer instruction does not establish a general downgrade facility and does not validate 3.22 to 3.14.

Official 3.30 notice: https://www.pioneerdj.com/en-us/news/2025/important-notice-cdj-3000-firmware-ver330/

Unrooting and downgrading are different. Removing a root overlay does not change OEM firmware 3.22 back to 3.14.

## Architecture

Conceptual boot flow:

```text
untouched OEM boot
  -> removable rooted p8 overlay launcher
      -> maintenance bypass requested? -> stock EP122
      -> activation state missing/malformed/disabled? -> stock EP122
      -> unit identity mismatch? -> stock EP122
      -> EP122 hash/revision mismatch? -> stock EP122
      -> slot/target/guard/protection mismatch? -> stock EP122
      -> one-shot authorized? consume + sync authorization before launch
      -> exact checks pass? launch stock EP122 with unit-bound DSO preloaded
      -> DSO transaction fails? restore original pointers/protections and refuse
      -> abnormal exit? persist disabled before the next launch
```

The OEM firmware image and EP122 on disk remain untouched. The loader selects stock EP122 or stock EP122 with the DSO. “Fail-closed” means known mismatches refuse pointer changes; it does not mean brick-proof. Power loss, storage faults, bootloader problems, loader failures, or unmodeled hardware/timing paths can still prevent normal boot.

## Hook behavior contract

The implementation wraps stock event handlers rather than replacing the application.

### Hot-cue change

- Call or preserve stock behavior as required by the analyzed contract.
- Arm or preserve a gate session only when a valid Hot Cue is pressed while playback was stopped.
- Track active cue/session state locally.
- Do not alter behavior for invalid cues or unrelated states.

### Hot-cue release

- On intermediate releases, preserve the active session as modeled.
- On the final release of an active and unlatched gate session, pass the local mode-1 operation into stock code so the existing backCue path is taken.
- Outside a valid active session, use stock behavior.

### PLAY

- During an active gate session, consume the queued PLAY interaction and latch playback.
- Once latched, releasing the hot cue must not back-cue the track.
- Outside a gate session, call stock PLAY without behavioral changes.

Do not claim every CDJ-3000X nuance is reproduced. The validated scope is the tested hold/release and PLAY-to-latch interaction.

### Player-info paint / native UI

- Call the original stock paint handler first.
- Draw and register the Gate Cue control only for the exact known player-info geometry.
- Read one atomic enable state for both rendering and behavior hooks.
- When disabled, clear the active gate session and route Hot Cue change, Hot Cue release, and PLAY exactly to their original stock handlers.
- Repaint only the control's visual rectangle after a toggle.
- Draw nothing and do not accept input when component bounds or coordinate translation are unknown.

## Native Gate Cue on/off UI implementation contract

This section records the exact EP122 revision 15034 implementation facts needed to reproduce the physically validated on-screen control. They are firmware-profile constants, not portable JUCE ABI and not promises about any other firmware.

### Fourth guarded hook

| Field | Exact value |
| --- | --- |
| Widget/path | NormalPlayerInfoWidget paint |
| Vtable slot | `0x0216e990` |
| Expected original target and guard address | `0x0166f178` |
| Required first 16 bytes | `fd7bbca9e2fffff042803f91fd030091` |
| Order | Call stock paint first, then draw/register the Gate Cue control |

The loader must verify this fourth slot, original target, guard, and mapping protection in the same transaction as the three behavior hooks. A mismatch refuses all interposition; partial installation is failure.

### Embedded JUCE call addresses for this exact build

| Function | Address |
| --- | --- |
| `juce::Graphics::setColour` | `0x01aed0d0` |
| `juce::Graphics::fillRect` | `0x01aed610` |
| `juce::Component::internalRepaint(Rectangle<int>)` | `0x01bc4300` |
| `juce::Component::addMouseListener(MouseListener*, bool)` | `0x01b7c590` |

Resolve and call the exact embedded entry points only after the exact firmware fingerprint and the fourth hook guard pass. Revalidate addresses, calling convention, and object layout for every other build.

### Geometry and rendering

- Active player-info strip bounds: width `1280`, height `240`.
- Visual rectangle: `x=752`, `y=32`, `width=104`, `height=40`.
- Full-layout equivalent when the component height is at least 600: `y=478`.
- Enlarged centered touch rectangle: `x=726`, `y=12`, `width=156`, `height=80`.
- Keep the touch rectangle above the overview waveform. The hit target is deliberately 1.5 times the visual width and twice the visual height.
- Draw the rounded pill with `fillRect` scan rows, avoiding a new font or graphics dependency.
- Draw compact custom 3x5 glyphs spelling `GATE CUE`.
- Active blue: ARGB `0xff007de1`.
- Inactive border: ARGB `0xff536570`.
- Inactive fill: ARGB `0xff171c20`.
- Active text: ARGB `0xffffffff`.
- Inactive text: ARGB `0xff8c9aa3`.

### Nested-child touch routing

A mouse-up hook attached only to the parent is not sufficient. Stock tempo/player-info child components intercept part of the apparent button, which caused the right portion of the first implementation to miss.

The validated solution is:

1. Create one static process-lifetime JUCE `MouseListener` object.
2. Register it once through `Component::addMouseListener` with `wantsNestedChildren=true`.
3. Receive `mouseUp` events from the parent and all nested children.
4. Start with `MouseEvent::eventComponent` and translate the local event coordinates upward through each component parent until reaching the player-info widget.
5. Bound traversal, for example to 32 parents, and refuse if the target is not reached or geometry is invalid.
6. Hit-test against the enlarged `156x80` touch rectangle, not the visual pill alone.

Validated object offsets in this EP122/JUCE build:

| Object field | Offset |
| --- | --- |
| `Component` parent | `+0x18` |
| `Component` local x | `+0x20` |
| `Component` local y | `+0x24` |
| `Component` width | `+0x28` |
| `Component` height | `+0x2c` |
| `MouseEvent` x | `+0x08` |
| `MouseEvent` y | `+0x0c` |
| `MouseEvent` eventComponent | `+0x28` |

### Toggle state and repaint

- Store the Gate Cue enable state in an atomic boolean. The physically validated build defaults it to enabled once the DSO is authorized.
- On an on-to-off transition, reset any active gate session before returning.
- While off, the three behavior hooks call the original stock handlers without Gate Cue semantics.
- On every valid toggle, call the exact rectangle repaint entry point for the visual `104x40` bounds so the pill immediately changes state.
- The UI state controls behavior; the button is not a decorative status-only element.

### UI-specific validation

Host and emulator tests must cover:

- active and inactive colors and glyph layout,
- exact visual and touch geometry,
- unknown-bounds refusal,
- one-time deep-listener registration,
- parent-delivered and nested-child-delivered mouse events,
- left, center, right, top, and bottom touch edges,
- the nested-child right-edge case that failed in the parent-only implementation,
- coordinate translation and bounded traversal,
- repaint after toggle,
- clearing an active gate session on off,
- exact stock passthrough for Hot Cue change/release and PLAY while off,
- no collision with the overview-waveform target.

The physical sequence remains disabled-first, then a separately authorized one-shot. On the owner-controlled research unit, the visual control, full touch target, off-state stock behavior, and persistent version were validated on 2026-08-05.

## Preprocessed Stems R16 implementation contract

### Scope and architecture

R16 is a physically validated one-track proof of concept on the research unit. It does not run a source-separation model on the CDJ and does not make arbitrary Rekordbox tracks stem-ready.

The prepared-media contract is:

1. The ordinary Rekordbox-exported full track remains the canonical track.
2. A computer creates an exact sample-aligned 96 kHz floating-point vocal sidecar for that exact track.
3. Vocal waveform analysis is prepared before export so the large and overview waveforms can swap without analyzing audio on the deck.
4. The deck validates the expected media and opens the prepared resources.
5. The deck performs only lightweight runtime routing and arithmetic:
   - BOTH: `output = full`.
   - VOCAL only: `output = vocal sidecar`.
   - INSTRUMENTAL only: `output = full - aligned vocal sidecar`.
6. The rear USB connection is not in the audio or compute path. It is optional after launch and was used only for diagnostics and deployment.

Subtraction quality depends on exact sample alignment and gain/format agreement. A similar filename, nearby analysis entry, re-encoded track, truncated sidecar, or sidecar from another export is unsupported and must not be guessed into service.

### Media discovery: support both observed mount roots

Do not hardcode a single front-media path. The emulator and physical deck may expose the same logical USB at different roots, including:

- `/media/usb/sda1`
- `/media/usb/sdb1`

The physical failure mode matters: R16 rendered the STEMS tab while waiting for sidecar readiness at the hardcoded `sdb1` path, but the research deck had mounted the front media at `sda1`. Touches appeared to do nothing because the action was gated on a readiness state that could never become true. A temporary alias made the tab work and proved the diagnosis; that alias is not a permanent design.

Permanent discovery must:

1. Enumerate only the expected removable-media roots.
2. Resolve canonical paths without following an unbounded or owner-controlled path chain.
3. Require the exact expected full track, sidecar, waveform analysis, and Rekordbox identity under one coherent selected media root.
4. Validate hashes, file type, sample rate/format, channel and length expectations, sample alignment, readable ownership/mode, and non-ambiguity.
5. Select exactly one valid candidate. Zero or multiple valid candidates means not ready and must emit a diagnostic.
6. Cache readiness only for the mounted media generation; invalidate it on eject, remount, track change, file change, or read error.
7. Fall back to stock/full-track behavior without partial Stems activation on any failure.

If the tab is visible but unresponsive, inspect media discovery and readiness before changing JUCE hit targets. Record which candidate roots were checked, which exact guard failed, and whether the sidecar and analysis files were opened successfully. Do not log private media paths or identifiers into public artifacts.

### Runtime, UI and waveform behavior

- Both VOCAL and INSTRUMENTAL start active, which means the untouched full track is heard.
- Turning INSTRUMENTAL off selects the prepared vocal sidecar and swaps the large waveform to the prepared vocal waveform. The overview waveform should swap too when the validated analysis resource is available.
- Turning VOCAL off while INSTRUMENTAL remains active selects the aligned subtraction path.
- Tab state must remain mutually exclusive with Beat Loop, Key Shift, and Beat Jump while playing and while paused. Validate both conditions; paused-state event behavior differed during development.
- Optimize touch-to-action latency only after correctness and readiness guards remain intact. Avoid work, path scanning, hashing, allocation, or media parsing on the real-time audio or UI action path.
- Apply short, validated transitions at discontinuities. The proof-of-concept pause/play click was reduced with fades; test quiet and loud material and do not claim click-free behavior from one cue point.
- The full waveform must return when the full mix is restored. A blank vocal waveform means the stock waveform was hidden but prepared vocal analysis was not loaded or bound; diagnose analysis readiness rather than faking display data.

### Required guards and failure behavior

Stems activation must be subordinate to all existing unit, firmware, EP122 hash, vtable, memory-protection, owner-approval, and activation-state gates. In addition, require:

- exact full-track identity and hash,
- exact sidecar identity and hash,
- expected 96 kHz floating-point format and declared channel/layout contract,
- exact frame length and sample alignment,
- expected prepared waveform-analysis identity and bounds,
- one unambiguous validated media root,
- successful file opens and safe read behavior,
- sufficient memory and initialization success before exposing an active UI state.

On any mismatch, missing file, malformed analysis, ambiguous mount, underrun, allocation failure, or unexpected read error:

- do not perform partial or guessed stem mixing,
- restore or retain the stock full-track path,
- clear the active Stems readiness state,
- keep Gate Cue behavior independent,
- provide a bounded diagnostic suitable for local troubleshooting,
- preserve the disabled/maintenance escape path for the next launch.

### Emulator-first and physical validation sequence

Before a physical write, test with the exact owner-supplied prepared media in the emulator:

- media present at `sda1` and `sdb1` independently,
- no media, both candidate roots present, stale mount, eject/remount, and malformed path,
- full-track, sidecar, waveform, hash, length, format, and alignment mismatch refusals,
- Both, Vocal, and Instrumental audio paths,
- large and overview waveform restoration and swaps,
- tab mutual exclusion while playing and paused,
- touch target edges and nested-child delivery,
- button-to-action latency without hashing or allocation on action,
- play, pause, cue, seek, hot cue, loop and track-load transitions,
- quiet and loud pause/play discontinuity tests,
- abnormal exit, stock fallback, rollback, and clean relaunch.

Hardware must still follow disabled-first staging, a separately authorized one-shot, owner testing, disabled restoration, reboot, and stock-return proof. Persistent activation is a new approval only after those tests pass. The R16 one-track success is not permission to persist a generalized build or process unvalidated tracks.

### Intellectual-property boundary for prepared media

Do not publish, upload, commit, or redistribute the research track, vocal sidecar, derived instrumental, Rekordbox export/database, waveform analysis, media image, or hashes that identify private media. A public implementation may include only original code, blank metadata templates, synthetic audio fixtures, synthetic waveform fixtures, guard logic, and redacted logs. Each owner must create lawful preprocessing inputs locally.

## Public and private profiles

The public firmware profile may contain:

- product and exact firmware version,
- EP122 revision and full hash,
- vtable slots,
- expected original targets,
- function guard bytes,
- validated embedded JUCE call addresses and object-layout offsets,
- UI geometry, colors, event-routing contract, and refusal rules,
- test definitions and refusal rules.

The private device profile must be local and gitignored. A template may contain placeholders such as:

```yaml
device_profile:
  serial: <local-only>
  emmc_cid: <local-only>
  usb_identity: <local-only>
  owner_key: <local-only>
  activation: <generated-local-only>
```

Never publish a filled profile, the unit-bound DSO, the generated overlay, activation values, or hashes that disclose owner authentication material.

## Inputs and intellectual-property boundary

The owner must lawfully supply OEM inputs and local extraction capability. This guide hosts neither firmware nor keys.

Do not publish, redistribute, upload to an AI service, or commit:

- OEM `.UPD` packages,
- extracted EP122 or decrypted OEM root filesystems,
- vendor or update AES material,
- device or partition images,
- serial numbers, full eMMC CIDs, USB identity, or U-Boot environment,
- owner SSH material, authorized_keys hashes, host keys, or activation tokens,
- built unit-bound DSO or overlay,
- Ghidra/decompiler projects containing vendor code,
- music, Rekordbox libraries, or media backups.

Do not publish the original research workspace or its Git history. Create a new clean repository by copying from an explicit allowlist. Run secret scanning before every public push and add an explicit license for original source.

## Per-unit build requirements

1. Accept the public firmware profile and a private local device profile.
2. Require user-supplied lawful OEM inputs; never fetch or bundle them.
3. Verify EP122 product/version/revision/full hash.
4. Verify all four expected vtable slots, original targets, first 16 bytes, and current mapping protections.
5. Verify the exact embedded JUCE call addresses, calling assumptions, player-info bounds, and object-layout offsets before enabling the native UI.
6. Compile an AArch64 position-independent shared object from original source.
7. Derive hook-symbol offsets from this exact newly built DSO.
8. Emit an artifact hash and a manifest tying the artifact to the public firmware profile and private unit profile without leaking secrets.
9. Generate the overlay in disabled state.
10. Reject stale artifacts, another unit's profile, unsafe file ownership/permissions, and any missing requirement.

Never make a memory page writable and executable simultaneously. A pointer patch transaction must use RX -> RW -> RX, verify the write, and roll back all already-modified slots if any later step fails. Partial patching is failure, not degraded success.

## Off-device test requirements

Before staging on hardware, test the state machine and refusal paths with host tests and an emulator appropriate to the supplied target environment.

Behavior cases:

- valid cue press while stopped,
- cue release without PLAY,
- PLAY-to-latch during a gate session,
- release after latch,
- multiple active cues and final release,
- repeated press/release,
- rapid cue switching,
- invalid cue,
- press while already playing,
- press while paused,
- ordinary PLAY outside a gate session,
- ordinary CUE/hot-cue behavior outside the modeled gate state.

Native UI cases:

- exact visual rectangle and enlarged touch rectangle,
- active and inactive rendering,
- compact `GATE CUE` glyph placement,
- one-time listener registration with `wantsNestedChildren=true`,
- parent and nested-child mouse delivery,
- coordinate translation from `eventComponent` to the player-info widget,
- left, center, right, top, and bottom hit testing,
- bounded traversal and unknown-geometry refusal,
- explicit rectangle repaint after toggle,
- active-session reset and exact stock handler passthrough while off,
- no overview-waveform collision.

Refusal and recovery cases:

- wrong product,
- wrong version or revision,
- wrong full EP122 hash,
- wrong unit identity,
- wrong vtable slot content,
- wrong original target,
- wrong 16-byte guard,
- unexpected memory mapping/protection,
- missing, malformed, stale, or conflicting activation markers,
- unsafe file owner or mode,
- failed mprotect,
- failed pointer write or verification,
- failed rollback,
- abnormal process exit or signal,
- inability to persist disabled after abnormal exit,
- maintenance bypass.

## Mandatory physical sequence

Do not combine the approvals below.

### 1. Read-only qualification

- Confirm owner control and research authorization.
- Record only the minimum local identity required.
- Confirm installed firmware and verified root/SSH status.
- Check the hardware advisory.
- Confirm stable power, lawful OEM inputs, backups, recovery media, and maintenance access.
- Confirm the deck has a stable stock baseline. Do not use this project to repair an already-glitching unit.

### 2. Root prerequisite, if and only if eligible OEM 3.14

- Follow the independent cdj3k-root v3.14 documentation exactly.
- Verify recovery and shell access.
- Understand that the audited overlay exposes key-authenticated Dropbear root SSH on all IPv4 and IPv6 interfaces. Use an isolated network, restrict access, or remove root when no longer needed.

### 3. Untouched OEM 3.22 update, if required

- Obtain separate owner approval.
- Remove Gate Cue and other experimental launcher changes; preserve the known/audited root prerequisite unchanged if relying on root survival.
- Follow AlphaTheta's official update guide with stable power and only the intended updater on the USB media.
- Boot stock first.
- Test track load, audio, PLAY/CUE, hot cues, waveform, media handling, and shutdown.
- Verify root survived; do not assume it.

### 4. Fresh unit profile and build

- Fingerprint the exact target.
- Build locally from original source and user-supplied inputs.
- Run all tests.
- Generate a unit-bound artifact and manifest with activation disabled.

### 5. Disabled-first overlay staging

- Obtain separate owner approval for the write.
- Install the removable overlay with no one-shot or persistent authorization.
- Reboot.
- Prove the launcher selected stock EP122.
- Repeat the baseline-control checks.
- If anything is unstable, remove the overlay and investigate. Do not activate.

### 6. Atomic one-shot test

- Explain the exact test and obtain separate owner approval.
- Arm one test boot atomically.
- Consume and sync the one-shot authorization before starting EP122.
- Let the owner load a known track and test Gate Cue plus baseline controls.
- Test the native control in both states: visual update, full left/center/right/top/bottom touch target, stock Hot Cue/PLAY behavior while off, and Gate Cue behavior while on.
- Be prepared to power down if behavior diverges.

### 7. Stock-return proof

- Restore disabled.
- Reboot.
- Prove stock EP122 launches without the DSO.
- Repeat baseline-control checks.
- Persistence must not be discussed as automatic promotion from one-shot success.

### 8. Persistent activation

- Explain the remaining risk and obtain a new, separate approval.
- Enable the explicit persistent marker.
- Verify disabled still overrides persistent.
- Verify maintenance bypass still works.
- Reboot and test.
- Document exact removal and keep recovery materials.

## Activation state rules

Priority must be:

1. maintenance bypass or explicit disabled,
2. unsafe/malformed/unknown state -> disabled,
3. separately armed atomic one-shot,
4. separately approved persistent activation.

Requirements:

- Disabled always wins over persistent.
- One-shot authorization is consumed and synced before application launch.
- An unexpected nonzero exit or signal persists disabled for the next launch.
- If disabled cannot be persisted after a crash, hold maintenance/fallback rather than automatically reloading the DSO.
- Missing or malformed marker means disabled.
- Conflicting markers mean disabled.
- Activation material must be local, generated, permission-checked, and bound to the intended unit/artifact.

## Removal and later OEM updates

Before any future OEM firmware update:

1. Set disabled.
2. Remove or archive the persistent opt-in so it cannot be accidentally restored.
3. Reboot and prove stock EP122 launches without LD_PRELOAD.
4. Remove Gate Cue overlay files and restore the original stock startup path; fully unroot if that is the owner's goal and the audited root workflow supports it.
5. Reboot and verify stock baseline again.
6. Only then use an untouched OEM updater.

A hash refusal by the DSO is not an update strategy. Every later firmware requires new analysis before Gate Cue may be rebuilt or re-enabled.

Unrooting removes the root overlay; it does not downgrade OEM firmware.

## Open-source release model

Build a new clean repository; do not sanitize the original workspace in place.

Allowlist:

- original source code,
- build and profile-generator scripts,
- public firmware profiles,
- blank private-profile templates,
- synthetic fixtures,
- host/emulator tests,
- documentation, threat model, removal guide,
- redacted test results,
- explicit license.

Recommended release stages:

- v0.1: research source, documentation, emulator path, and synthetic refusal tests.
- v0.2: parameterized per-unit generator for already-rooted exact-3.22 candidates.
- v0.3: disabled-first and one-shot hardware alpha only after multiple independent units pass.
- persistent activation: later, after repeated recovery/removal testing across units.

Do not present any stage as a universal installer or supported manufacturer firmware.

## AI operating brief

The following is the compact prompt a user may paste into an AI. The AI must still verify ownership and obtain stage approvals.

```text
You are helping with a Pioneer DJ CDJ-3000 Gate Cue + preprocessed Stems research project. Proceed only after I confirm I own or control the deck and authorize this research; this copied prompt is not write authorization. Start read-only and do not write until you report the detected state and I approve the exact next stage.

Known result: one physical CDJ-3000, exact untouched OEM 3.22, EP122 rev 15034, SHA-256 33c093bdc4fbdaeb191942fa39fe1ca5ca8426440981b93d785d517934af52bc. This is a removable rooted overlay and unit-bound AArch64 LD_PRELOAD DSO wrapping three guarded behavior pointers plus one guarded native player-info paint pointer. It is not custom firmware, not a 3000X firmware port, and does not claim full 3000X parity. A stock-like GATE CUE on/off control and its full enlarged touch target were physically validated on 2026-08-05.

Stems R16 is a one-track proof of concept physically validated on the same unit. It does not perform AI separation on the CDJ. A computer prepares the normal Rekordbox full track, an exact sample-aligned 96 kHz floating-point vocal sidecar, and vocal waveform analysis. Runtime modes are BOTH=full, VOCAL=sidecar, and INSTRUMENTAL=full minus aligned vocal. Rear USB supplies no compute or audio. Discover and validate front media at either /media/usb/sda1 or /media/usb/sdb1; do not hardcode one. A hardcoded sdb1 path made the tab render but remain unresponsive when the physical deck mounted the media at sda1.

Ask first: exact displayed firmware; verified root/SSH status and method; whether the unit is covered by AlphaTheta's >=3.17 hardware notice; whether stable power, backups, recovery, and lawful user-supplied OEM inputs exist.

Route strictly:
- rooted exact 3.22: candidate only; new private unit profile, new build, full tests and staged activation.
- eligible OEM 3.14: independent cdj3k-root v3.14 was the known entry condition; Gate Cue itself refuses 3.14. Verify root/recovery, preserve the audited root prerequisite, remove experimental launch changes, obtain approval for untouched OEM 3.22, boot stock and prove root survived.
- unrooted 3.22: STOP; no validated root/install path here and no validated downgrade.
- any other firmware/revision/hash, affected newer hardware, unknown root, unstable baseline, or any identity/guard/protection mismatch: STOP and report.

Never use another unit's binary/profile. Derive DSO symbol offsets from the new artifact. Never create W+X memory; patch RX->RW->RX transactionally and roll back all changes on failure. Default stock; disabled beats persistent; malformed or crashed means disabled; keep maintenance bypass.

Native UI contract for exact EP122 rev 15034 only: add a fourth hook at NormalPlayerInfoWidget paint slot 0x216e990, expected target/guard address 0x166f178, guard fd7bbca9e2fffff042803f91fd030091, and call stock paint first. Exact embedded JUCE calls: setColour 0x01aed0d0, fillRect 0x01aed610, internalRepaint(Rectangle<int>) 0x01bc4300, addMouseListener(MouseListener*,bool) 0x01b7c590. For the 1280x240 strip, render x=752,y=32,w=104,h=40 and hit-test the centered x=726,y=12,w=156,h=80 target. Register one process-lifetime MouseListener with wantsNestedChildren=true; translate coordinates from eventComponent through the parent chain before hit-testing. Validated offsets: Component parent +0x18, x/y +0x20/+0x24, width/height +0x28/+0x2c; MouseEvent x/y +0x08/+0x0c, eventComponent +0x28. Bound traversal and refuse unknown geometry. Store enable state atomically; off clears the gate session and calls original Hot Cue change/release and PLAY handlers; toggle explicitly repaints the visual rectangle. Treat all addresses and layouts as guarded firmware-profile facts, never portable constants.

Stems contract: exact media identity/hash, sidecar format/length/alignment, prepared waveform identity, unit binding, firmware fingerprint and one unambiguous mount root must all pass. Fail to stock/full-track behavior with a diagnostic on missing, malformed, ambiguous or unreadable media. Diagnose a visible-but-unresponsive Stems tab as a readiness problem before changing touch geometry. Test Both/Vocal/Instrumental, waveform swapping, play/pause/cue, loud and quiet discontinuities, tab switching while playing and paused, sda1/sdb1 discovery, refusal paths, eject/remount, rollback and stock return in the emulator first. Keep hashing, path discovery, allocation and parsing out of the touch/audio action path.

UI validation: host tests plus emulator clicks at left/center/right/top/bottom, including nested-child delivery and the right edge; verify no overview-waveform collision, on/off rendering, session reset, stock passthrough while off, and repaint. Then retain the separate disabled-first, one-shot, stock-return, and persistence approvals.

Never publish OEM firmware, EP122, decrypted rootfs, keys, device dumps, full serial/CID, SSH material, activation values, the research track, sidecar, Rekordbox database, waveform analysis, media image, decompiler projects, or unit-bound artifacts. Require lawful owner-supplied OEM and media inputs plus local extraction/preprocessing capability.

Required sequence with separate approvals: read-only inventory -> verified backup/recovery -> untouched OEM 3.22 if eligible/needed -> stable stock baseline -> per-unit build and off-device tests -> approval to stage disabled -> reboot/prove stock -> approval for atomic one-shot -> owner test -> restore disabled/reboot/prove stock -> separate approval for persistence. Before future OEM updates, fully disable/remove and verify stock.
```

## Primary references

- Independent cdj3k-root repository: https://github.com/emmaworley/cdj3k-root
- Independent cdj3k-root v3.14 release, explicitly for official firmware 3.14: https://github.com/emmaworley/cdj3k-root/releases/tag/v3.14
- AlphaTheta CDJ-3000 firmware 3.22 notice: https://www.pioneerdj.com/en/news/2026/cdj-3000-firmware-update-322/
- AlphaTheta firmware 3.30 suspension and specific 3.30-to-3.20 remediation: https://www.pioneerdj.com/en-us/news/2025/important-notice-cdj-3000-firmware-ver330/
- AlphaTheta newer-hardware notice requiring 3.17 or later for affected units: https://www.pioneerdj.com/en/news/2024/important-notice-cdj-3000/
- AlphaTheta official CDJ-3000 update guide: https://support.alphatheta.com/en-us/articles/4413929605529

## Open-source acknowledgements

The work depended on the following open-source projects that were actually used. Inclusion does not imply that any project or maintainer endorses this modification.

- Root prerequisite: cdj3k-root and its exact v3.14 release — https://github.com/emmaworley/cdj3k-root and https://github.com/emmaworley/cdj3k-root/releases/tag/v3.14
- Reverse engineering and emulation: Ghidra — https://github.com/NationalSecurityAgency/ghidra ; QEMU — https://gitlab.com/qemu-project/qemu
- Scripted binary inspection: Capstone — https://github.com/capstone-engine/capstone ; pyelftools — https://github.com/eliben/pyelftools
- Reproducible AArch64 build and verification environment: Docker CLI — https://github.com/docker/cli ; Ubuntu — https://ubuntu.com/community/ethos ; GCC — https://gcc.gnu.org/ ; GNU Binutils — https://sourceware.org/binutils/
- Offline firmware inspection support: Python cryptography — https://github.com/pyca/cryptography
- Native UI runtime analyzed and called by the guarded overlay: JUCE — https://github.com/juce-framework/JUCE

## Final boundary

The result is real but narrow: one unit, one exact OEM build, one carefully staged runtime overlay, and one prepared track for the Stems R16 proof of concept. A competent reproduction effort should preserve that precision. If a state is not explicitly supported above, stop safely and start a new research track instead of forcing the known artifact onto an unknown deck or track.