Jog displays and screens: what can and cannot be mapped.

A question eventually appears in every mapping forum: “my controller works, but the jog screen does nothing; how do I map it?”.

The short answer is that you do not map it. The longer answer is more interesting, because it explains exactly where mapping ends and something different is required.

What the jog screen shows

Start by knowing which information lives there, to understand why MIDI cannot accommodate it.

In official CDJ-3000 documentation, the central jog screen shows playhead position and artwork for the loaded track, as a quick visual reminder. Controllers usually add the waveform, BPM and remaining time.

Notice the nature of that information: these are not states changing occasionally, like a loop button. They are data refreshed continuously while music plays. The waveform moves, time decreases, the playhead advances.

That detail is the key to everything that follows.

Why MIDI cannot reach that far

Two reasons, both structural:

1. Bandwidth. MIDI is designed for short, occasional messages: “a button was pressed”, “this knob moved”. A real-time waveform requires constant refresh, which is not what the protocol does well. VirtualDJ documentation says so when explaining HID’s contribution: extensive LCD screens with text lines without MIDI’s usual bandwidth problems.
2. The communication model. In MIDI, the controller forces messages even when the application is not ready to process them. In HID, software requests data when it can handle it. For continuous refresh, the second model is the only sensible one.

A third, subtler reason appears when you examine this inside software: in Traktor’s mapping table, rich hardware elements do not appear as numbers you can type, but as control names — the documentation gives examples such as Left.Jog.Encoder — because the device speaks the manufacturer’s own protocol or HID.

In other words, MIDI failing to reach them is not the only issue. Those elements are not even presented as MIDI messages.

What can be mapped through MIDI and what needs a separate protocol

The table makes the boundary clear. It is a friendly boundary: the top group works identically with screens off. A controller “working halfway” is therefore usually a complete controller missing its HID layer.

The case that demonstrates it, with a name

A community project for the DDJ-FLX10 documents this better than any theory. Its opening statement is striking:

A MIDI-only configuration gives you a fully functional controller. This extension adds the jog screens supplied “as standard” with Serato or rekordbox.

That says it all. MIDI gives you the entire controller. Screens are not “a part still needing mapping”: they are another layer, one the manufacturer’s official software takes for granted because it has access to information you do not.

What each part does

The project divides work into two pieces, and the division is instructive:

The MIDI mapping handles buttons, LEDs, jog rotation and effects. In other words, everything you already knew how to map. But it also does something beyond mapping: a SysEx handshake — an exchange of system-exclusive messages — that unlocks the HID screen.

The HID layer handles the screen. A script sends a status packet every 100 ms with playhead position, remaining time and BPM. A Python helper process does the heavy work: opens the hidraw device, reads waveform analyses already calculated by the software, converts them into the manufacturer’s own waveform format, and uploads them to the equipment, with a periodic trickle keeping the firmware’s waveform buffer alive.

Why both pieces are needed

Here is the guide’s most valuable technical detail, explaining why even an elaborate mapping does not solve this.

A DJ application’s scripting environment cannot:

• Read binary files (waveform analyses are compressed and in a proprietary format).
• Decompress data.
• Open USB endpoints with arbitrary-sized HID reports.

None is an arbitrary programme restriction: they are limits of the environment running a mapping script. All three are needed to draw a waveform on another device’s screen.

That is why a separate process with elevated permissions is needed outside the software. A mapping cannot leave its box.

Before trying: what the unlock involves

Projects like this include a manufacturer unlock step enabling the screen interface, which otherwise stays closed.

I will not explain how to do it, and that is deliberate: this section’s editorial rule explicitly says that access to closed interfaces is covered through architecture, context and risks, without publishing bypass instructions or keys. I consider that the correct position, and the useful one: whether this suits you depends on its implications, rather than the procedure.

According to the project’s own documentation, those implications are:

• Elevated permissions are required. The helper process needs low-level device access.
• It is repeated on every connection. It is not a one-time configuration: repeat it whenever you plug in.
• Software developer mode is required.
• It adds pieces that can fail. A faulty mapping can be fixed; a background process crashing halfway through a gig cannot.
• It is outside all warranty and support. It is not a documented supported function, but a community interoperability project.

That is the actual balance. For a laboratory or understanding your equipment’s internals, it is fascinating. For DJing, it is too many pieces.

What to expect in each application

An honest summary, because expectations are often formed badly here:

• With the manufacturer’s official software: screens work without you doing anything. They are covered by the proprietary protocol, which is why they “come as standard”.
• With other software, over MIDI: you get the complete controller with screens off. Buttons, LEDs, jog, effects. Everything except visual information.
• With other software, using native HID: it depends on support for the particular model. When supported, this is the clean route without a helper.
• With other software, using HID with an unlock: this is the FLX10 project’s case. It works as an interoperability exercise, rather than a booth solution.

The manufacturer-side fact closing the debate: Serato lists Numark Dashboard — a display device — among accessories that cannot be remapped at all. When the manufacturer excludes exactly the product built around a screen from mapping, the message is clear.

Common mistakes

• Looking for the screen in the assignable-function list. It is absent because it does not communicate over MIDI.
• Concluding the mapping is wrong because the screen is blank. The mapping may be perfect; another layer is missing.
• Confusing “does not work” with “cannot be mapped”. It works in official software, which is the point.
• Trying to refresh a waveform over MIDI. It is a bandwidth problem, rather than effort.
• Setting up an unlock for a gig. A manual step per connection and a root process are not a booth plan.
• Assuming your software’s HID support covers your particular model. Check model by model, rather than brand.

Next step

You now know where mapping ends and something else begins: when an element is a protocol rather than a MIDI message, the only route is understanding that protocol. That has a name, a method and rules: reverse engineering DJ hardware, exactly the next subject.