Controlling LEDs and colours through a mapping.

LEDs are the most neglected part of mapping and the part that changes the experience most. A mapping with state feedback can be operated in darkness; one without it forces you to look at the screen whenever unsure. The difference is completing output assignments, rather than hardware.

That is the first misunderstanding to resolve: a button lighting is not part of its button assignment. They are two different mappings.

Input and output are two different mappings

A mapping has two directions, best considered separately:

• Input: what equipment tells software. “This button was pressed.” Decides what the function does.
• Output: what software tells equipment. “Switch this light on.” Decides what is seen.

That explains the common, confusing symptom: the button works but does not light. It is not a failure: half the work is complete. Input is assigned and output does not exist.

There is even a useful diagnostic consequence: because output is a separate assignment, the LED can display the wrong state while the function works, and vice versa.

How an LED is actually illuminated

A convention applies to almost all hardware, explained by this guide’s three sources:

Buttons usually control their LEDs by sending a short message with the same first two bytes as the controller sends when the button is pressed.

Practically: if your button sends 0x91, 0x11, 0x7F when pressed:

• Sending 0x91, 0x11, 0x7F turns the LED on.
• Sending 0x91, 0x11, 0x00 turns it off.

The LED and button therefore share an “address”. Only the sender and the third byte change.

Colour: usually the third byte

If the LED has several colours, colour is usually determined by the third byte. The same message with a different value gives another colour.

The key to keeping it manageable: store colour codes in a named table rather than scattering numbers throughout code. In practice, it separates a mapping you can adjust in two minutes from one you dare not touch.

Where LEDs are enabled in each application

It depends on the programme, each naming it differently:

• rekordbox: MIDI OUT is the code sent to equipment. A convenient detail: if the function includes an indicator, the same MIDI IN code is automatically sent to MIDI OUT, so in many cases the LED works without intervention. There is also an Indicator control type specifically for sending lighting information, with an important restriction: you cannot assign its function by operating the control; write the code in MIDI OUT manually.
• Traktor: an I/O column distinguishes inputs and outputs. Outputs let the controller display software state, appearing as lit or flashing LEDs. A rule worth knowing: manual assignment is the only way to assign an output control. There is no “Learn” to solve it.
• Mixxx: scripts send MIDI back to the controller, with one function for short messages and another for SysEx.

The pattern recurs everywhere: output is more manual than input. Learning by moving a control works only for input.

The mistake that desynchronises every LED

This guide’s most valuable design advice comes from Mixxx documentation:

Do not send LED messages directly from input-handling functions. Change a software control’s state and send MIDI from a callback reacting to that change.

The reason is clear: if the LED reflects actual software state, the controller remains correct even when the user uses a keyboard, mouse or another controller. If you instead illuminate it because “the button was pressed”, it lies as soon as state changes another way.

Consider a real case: a loop button and its LED. If you enable the loop with the mouse, an LED reacting only to the button stays off, making you believe the loop is inactive. Live, that is a serious error.

The practical rule: the LED must read state, rather than remember the last press.

When the manufacturer does not document codes

This is where many people get stuck. Not every manufacturer publishes its equipment’s output-message list.

Documentation recommends intercepting messages in that case:

• Controller debugging mode, logging every incoming and outgoing MIDI message.
• A MIDI monitor, such as MIDI-OX on Windows or MIDI Monitor on macOS.

The method is simple but laborious: move the control in the manufacturer’s official software, observe which message leaves, and reproduce it in your mapping.

That documentation work later enables support for a previously unsupported controller, and opens the door to reverse engineering covered later in this block.

Switching LEDs off on shutdown

A small detail revealing a well-maintained mapping: without switching LEDs off when the programme closes, they may remain lit on equipment.

The solution is the same as switching on, at the other end: send the off state in the controller’s shutdown function. It is a classic, visible case the user sees whenever they finish DJing.

Applications with scripting provide that shutdown function, which is where it belongs. In applications with an output column, ensure the programme’s initial state matches the equipment’s.

Common mistakes

• Assuming the LED is included with the function. It is not: it is an output assignment.
• Looking for “Learn” on output. Traktor output assignment is manual by design.
• Sending LEDs from the button function, desynchronising them when using the mouse or keyboard.
• Scattering colour numbers throughout code instead of storing them in a named table.
• Not switching LEDs off on shutdown, leaving them lit.
• Assuming the manufacturer documents output codes. Often it does not, and they must be intercepted.
• Confusing a failed LED with a wrong mapping. Usually only the output half is missing.

Next step

Visual feedback is now resolved, making a mapping feel professional. The equipment element causing the most problems and the greatest protocol differences remains: jog wheels. There, the issue is which protocol your controller uses, rather than mapping well or badly — exactly the next subject.