What Bome MIDI Translator Is and When You Need Middleware.

One kind of problem defeats any mapping, however well made: the function you need does not exist in the software.

It is not hidden in a menu or waiting to be enabled. It simply is not in the list of assignable functions. Mapping cannot assign something that does not exist.

That is where middleware enters: a program between the controller and software that creates the missing function.

What MIDI Middleware Is

The idea is simple: receive messages from your equipment, transform them and forward them.

The difference from mapping is what changes:

• A mapping determines which software function a control triggers. The message stays the same.
• Middleware can change the message itself: its type, channel or value. It can also do things outside normal mapping, such as turning a MIDI message into a keystroke.

That last capability is the key, stated in the product’s own documentation: keyboard and mouse emulation allow any program on the computer to be controlled from a MIDI controller.

Consider what that means. A program with no MIDI support whatsoever, whether a player, utility or anything else, becomes controllable from your booth because the controller talks to the translator and the translator types on the keyboard.

The Specific Case That Justifies It

This has a concrete, much-sought example:

Making a DDJ-1000’s jog displays work in Traktor.

It meets all three conditions: a function the software does not expose, wanted by many people, with a community solution that explicitly requires middleware. The reference mapping repository specifically lists the DDJ-1000 with jog displays among its main mappings, and its folder contains versions with and without Bome.

“With Bome” is the reason it works, rather than an installation detail.

This fits the display guide’s point: driving an unsupported display is an interoperability project rather than a mapping. That case used a script and auxiliary Python process; this uses a commercial translator. The problem is the same, with a different tool.

Bome’s Model: Three Levels

Bome MIDI Translator Pro organises everything into three levels. Understanding them explains its flexibility.

The Project

A Project is a file you can load and save. It contains:

• Project author information.
• Default MIDI input ports.
• Default MIDI output ports.
• The MIDI router, defining pass-through connections for the entire project.
• All presets.

Default ports work through inheritance: unless specific ports are defined at a lower level, those from above are used.

The Preset

A Preset is a collection of translators, enabling conditional behaviour:

A preset can be active or inactive; when inactive, its translators are completely ignored during processing.

Crucially, another translator’s output action can enable or disable a preset.

That gives you layers. A button changes which rule set is active, rather than simply doing two things, and everything else then means something different. It is the idea of a SHIFT layer implemented outside the software without its limits.

The Translator

The Translator is where work happens. The documentation describes it as the component doing your project’s work, because it defines the condition and reaction.

Each translator has four elements, the skeleton of any recipe:

1. Options: name, active/inactive status and stop processing.
2. Incoming trigger: the condition. Accepts MIDI messages, typed keystrokes and internal events, such as preset activation or timer expiry.
3. Rules: simple logical and mathematical statements for advanced uses. Decisions can depend on values rather than only which message arrived.
4. Outgoing action: what happens. Send MIDI, emulate typing a key or change internal behaviour by activating presets or starting timers.

Notice the symmetry: input can be a key and output MIDI, or vice versa. The translator is bidirectional in the endpoints it connects, which is where its power lies.

How an Event Is Processed, in Order

This detail explains apparently magical behaviours, and documentation describes it precisely:

An incoming event is processed in order. First, the first translator of the first preset, then the second, continuing through all that preset’s translators. Processing repeats for the second preset until the event has passed through every translator of every preset.

There is a stop: if a translator with stop processing enabled triggers, the event is interrupted and subsequent translators and presets do not see it.

In practice:

• If two translators do contradictory things, order decides which wins.
• To prevent a message reaching the software, consume it with a translator stopping processing.
• When something fails in a complex project, the usual cause is an earlier translator consuming the event.

Virtual MIDI and the Router

Two components appear as soon as you try it:

• Virtual MIDI ports exist only inside the computer and let DJ software “see” the translator as another device. The controller enters the translator, which outputs to software through a virtual port.
• The MIDI router defines pass-through connections for the whole project.

One tool saves hours: the event monitor, recording what enters and exits. It is the equivalent of DJ software debugging mode, revealing when a translator failed to trigger because its message never arrived.

When Mapping Is Enough and When a Translator Is Needed

The table organises the decision. The underlying rule: if a function exists in the software’s list, use mapping; if absent, it must be created outside.

The Cost: Another Intermediate Component

This often-overlooked part determines whether it suits you.

Middleware is another program in the chain, with real consequences:

• It must be running before you DJ. Otherwise, the equipment does not behave as expected.
• If it crashes, everything passing through it fails. It is a live process rather than a saved setting.
• It adds latency, small but real, because messages travel one more hop.
• It doubles configuration. Software mapping and external translation are separate; changes require remembering where they belong.
• It is an external dependency. A licence request or update on gig day can arrive during your set.

For a studio, session preparation or fixed setup, it is an excellent tool providing otherwise unavailable capabilities. For a booth where hesitation is unacceptable, it is another possible failure point.

Serious mappings depending on middleware therefore warn in their own documentation. Users must know there is a requirement outside the software. A mapping saying “requires Bome” now has a clear meaning and reason.

Common Mistakes

• Seeking middleware before exhausting mapping. Often the function exists and only needs finding.
• Installing it without starting it before DJing. Equipment appears broken when it is not.
• Forgetting processing order. An earlier translator consumes an event so later ones never see it.
• Not using the event monitor. It is the diagnostic tool revealing missing messages.
• Confusing middleware with a mod. Equipment is untouched; everything happens on the computer.
• Setting it up the night before a gig. A new live dependency needs testing in use.
• Failing to document both configurations. When something fails, you must look in two places.

Next Step

This completes Phase 2: mapping by ecosystem, layers, LEDs, jogs, displays, reverse engineering, capture and the intermediate layer. Throughout, the same practical questions recur: how to organise a mapping so it does not become chaos, and how to test it. That is exactly what comes next: designing a mapping from scratch, methodically.