Monthly Archives: June 2014

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.


Judder setlists. 6th June 2014

Hamst0r vs dBsurfeit


dBsurfeit – Drop the bloody torpedo
H: Revolucian – Bale Out
dBsurfeit – Born with these cold dead hands (Lady Gaga vs Combichrist)
H: Heavygrinder – Vulgar Walking
dBsurfeit – I, Bad Girl
H: Schmolli – Du Hast Sandsturm (Rammstein vs Darude)
dBsurfeit – Calypso Girl
H: Losers – Flush
Skindred – Set it off

Conrad ought to be able to expand on exactly what he’d mashed together, as it stands, all I have is guesswork and their titles to go on.

Hamst0r 1am-1.30

Prodigy – Their Law
Jane’s addiction – Been Caught Stealing (Metranohm mix)
Prodigy vs Sub Focus vs RHCP – Give it away bitch
Schmolli – Madonna’s carcass (request)
Subvibe – 30 million
Gry – Princess Crocodile (Sammy Senior mix)
Brainhunters – Snuff
Camisra – Let me show you
Jaldaboath – The J Team

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