Category Archives: Controller development

RDM DMX resources.

DMX to ethernet overview:

OSC to DMX, via Arduino

More adventures in Arduino (DMX shield)

Open Lighting Architecture on Raspberry Pi.


RDM is the extension for DMX that enables bi-directional communication between the controller and the devices.

This means that diagnostics can be done on the lighting via DMX.*

More RDM info:

*To investigate: Whether it’s possible to assign DMX addresses remotely over RDM DMX, then display all active devices and their control channels, with a view to creating a virtual lighting display, and programming lighting sequences on a PC.


Ins and Outs

Traktor breaks commands up into Ins (Going from the controller, hopefully doing something) and Outs (Feedback from Traktor to the controller.) Combining both of these allows two-way communication between the client and controller,so the position of any control remains constant across the system.

I will assume that readers will be familiar with how to put their TouchOSC user interface together, with appropriate controls
used for the tasks at hand. Care should also be taken to ensure that Channel and Number fields do not repeat.

Once we have a rudimentary UI, we are likely to have several groups which need to have their Ins and Outs assigned.


Allocating Ins is generally quite intuitive, especially with the reference articles given in the resources section. Outputs
aren’t always quite as straightforward. If simple feedback is all that’s required, the Output and input are mapped to the same MIDI signal.

LEDs are a little different, but provide a good insight as to how these things fit together:

Should signals interfere with each other, separate the controls in the group into more specific sections, and allocate a different MIDI
channel to each. Continue with this, refining your allocations so they start coincide with the original design.

Points of interest:

When using a touchpad, assign a value for x and y, these axes ought to also have the same channel, but different numbers, so that two functions can be allocated within Traktor, such as effect volume and pitch, separately, as indicated by our resources.

Note: Transport.

[Diagram to go here]

The controller(s)and client communicate by wireless network, normally hosted by one of the android devices.

Setting a device up as a hotspot I found to be more expedient than setting up an ad-hoc network, while still allowing
the OSC bridge to remain on the computer.

Having everything on an isolated network also minimises interference from other devices. A typical configuration
is shown below.

For example:

  • The ip address of the hotspot-device was
  • ipconfig of the computer, while connectd to the hotspot is
  • The second android device has the ip
  • The android devices will display their ip address in the OSC option of Touch OSC. The Touch OSC Bridge should be active on the computer and visible in the taskbar. The host and OSC bridge have, in this case, the same IP address as the computer, so these fields may be populated accordingly.

Words To The Wise

(Or, things I wish I’d done first time around, having learned the hard way)

Phase 1 – Gather Underpants Planning.
Instead of simply going ahead and making your Touch OSC file right away, I found it beneficial to map out what controls
are required for each ‘droid device. Knowing your requirements, and using your findings to already have the design hashed
out beforehand is crucial, especially when working out how to allocate the MIDI channels and the tracks contained therein.

Knowing the native resolution of the device you’re setting up as a controller is useful as, while aspect ratio may
remain more or less constant, and devices may well accommodate different resolutions, tailoring the size of the controller
will result in more accurate, and therefore better, control.

It’s worth noting, at this stage, that I broke down individual sections of the controller into different MIDI
channels, dependent on their function.

The categories I ended up with are:

1. Level sliders and crossfader, play buttons (L and R)
2. LEDs (Output)
3. Touchpad for FX bank 1
4. Tempo, pitch, deck selection
5. EQ levels, killswitches, master volume, monitor volume.
6. FX bank toggles, deck allocation, touchpad for FX bank 2
7. The Doom Button (everything else, further expansions)

Assuming that we have a more or less coherent idea of what we’re making and the constraints of our platform, it’s time to
create our interface…

Useful resources

Archive (Containing the Touch OSC apk, the OSC bridge and the UI Editor, RAR format.

MIDI mapping for Traktor.

MIDI Guide Traktor PRO (pdf) РThis document explains a large portion of the MIDI mapping, and how the eventual .tsi file will look.
The Traktor tsi file

The Galaxy UI file for Touch OSC
The Galaxy Tablet UI file for Touch OSC



Traktor Control via Android devices using Touch OSC

It was just before New Years’ Eve 2013. I was due to DJ at Shenanigans and my USB controller was on its last legs. ¬†Necessity drove me to come up with a controller that could allow me the same levels of freedom as before, but on a far more portable platform. There was a lot of work to be done, mostly research.

Eventually, I came up with a rudimentary prototype (using a Sony Miro as an initial platform) which served to both demonstrate that the theory was sound, and this was only the tip of the iceberg.  Further developments led to a second Android device being employed (A Samsung Galaxy Tab 3), and the Miro being replaced by a Galaxy S.

Subsequent investigations will discern whether the MIDI controllers could be modified as a remote input for either laser and/or lighting control – and how we would go about it…