BTouch Client Version 2

Bei der Entwicklung vom BetaTouch Client Version 1 bin ich seinerzeit ziemlich schnell an die Grenzen der Verwendeten Technologie gestoßen. Was will man machen, eine Entwicklungsumgebung, für die es damals schon seit ~15 Jahren keine Updates mehr gegeben hat, ….    macht mindestens mal bei der täglichen Arbeit absolut keinen Spaß mehr. Deswegen habe ich  um das Jahr 2013 (sofern ich mich richtig erinnere) damit begonnen, Eine bessere Version von Grund auf neu zu entwickeln.

Zu den gewollten Merkmalen gehörte eine möglichst große Flexibilität bei der Gestaltung der Oberfläche, einfache Erweiterbarkeit um neue Funktionen, Synchronisation via Netzwerk…..    und wenn’s neben Windows auch auf Linux liefe, wäre auch nicht schlecht.

Herausgekommen ist der ΒTouch Client Version 2  ( … btw: Das ist nicht der Buchstabe ‘B’, sondern ein ‘Beta’ …  #truestory ) .

Es ärgert mich übrigens maßlos, jawohl, dass ich es verpeilt habe, mit den Feldern wenigstens für das Foto irgendeine Form von ASCII-Art darzustellen. Scheibenkleister! Aber egal:

Die Software ist darauf ausgelegt, per Touchscreen bedient zu werden. Sie erlaubt die Steuerung unterschiedlichster Geräte(-kombinationen) durch nicht-geschultes Personal. Die Software eliminiert das Risiko von Fehlbedienungen und ist in der Lage, Multiroom-fähige Steuerkonzepte zu implementieren. Geräteabhängige Steuerprotokolle, Regelsätze, etc. können darüberhinaus verhältnismäßig leicht hinzugefügt werden.

Continue reading

I2C Daisy-Chain Module (“Zauberkästchen”)

Ich hab es an anderer Stelle schon einmal erwähnt: Seit mehreren Jahren arbeite ich mit Leuten an einer Lösung zur Steuerung von Geräten. Der ganze Bimmbamm hat sehr wenig bis ganz viel mit Automatisierung zu tun, geht aber an manchen Stellen darüber hinaus und ist an an verschiedenen Stellen sowieso ganz etwas anderes. Das Ding nennt sich BetaTouch.

Einer der Wege, die wir mal verfolgt haben, waren die ‘Zauberkästchen’. Daraus ist kein fertiges Produkt geworden, aber es gibt ein paar Bilder und ein wenig was zu erzählen. Hervorragend also für die Webseite.

Continue reading

Midi Theremin

This project is based on the idea of my buddy Matthias over at Visual Phi Events. The idea is simple: “Let’s do something with a Theremin controlling visuals. That’d be cool.”. Well, it surely is…

Fortunately we didn’t have to buy an original Theremin (for the price of an original Theremin) but could base our idea on the work of the Open Theremin Uno project.




Adding Midi to the Theremin circuit is as easy as soldering 3 wires to the board. Since it’s all based on the Arduino Uno it’s easier to link to the article on the Arduino website than writing it down myself.


For the first basic tests I connected the Theremin to a simple zoom-effect in VDMX:

The finished project was set up at the Sabinchenfest in Treuenbrietzen.


The two possible Midi data-streams (one corresponding to the Theremin tone’s pitch, the other one to the volume) were connected with a simple Quartz-Composer patch, controlling the angles of a cube. That was cool.


An idea that came up during the 31C3. The guys from VisualPhi had some motion sensors lying around and wanted to use them to control their VJ-software. That’s why I built them a Motion-Sensor-to-MIDI-Converter.

As usual it all starts on a breadboard. Most of the times I draw the schematics parallel to building the circuit on a breadboard. Guess that’s the usual way.




The circuit itself is rather unspectacular. 8 inputs are polled from a 74HC165. Then there’s a little bit of logic implemented within an Arduino and then there’s 16 LEDs, a rotary encoder and MIDI out.






This project is the first one to benefit from my new 3D Printer. Due to the fact that I don’t have a dedicated toolshed anymore it’s kind of impossible to reliably manufacture the case anymore. Seems as if I don’t need one from now on.



I really think the fixation of the rotary encoder is one of the smartest pieces ever done by mankind. Ever =)





The LEDs are driven via Charlieplexing. It’s rather easy to implement but you really need to concentrate while soldering. By the way: If everything else fails I guess I’ll become a Soldering-Artist one day.



The function of the device is easy to explain. Every input is triggered when the state of a connected switch changes. This is indicated by the red LED below the channel. The green LEDs indicate the channel that’s influenced by the rotary enoder: The encoder gives the possibility to set the time that has to pass from the moment the input is triggered until it can be retriggered again. Something like a ‘Retrigger Threshold’. The value can be set to values between 0 and ~2 seconds. When the lower / upper limit of the value is reached the green LED flashes. Pressing the rotary encoder (it has a built-in switch) switches to the next input.

A triggered input sends a MIDI note.










Arduino Audio-To-Midi

Or: Creating an audio-signal with an Arduino, feeding it into a mixing desk, altering the frequencies via the mixer’s eq and analyzing the processed audio with another Arduino which then turns it into a MIDI-signal. Yes, that is Digital-to-Analog-to-Digital-to-Analog-to-Digital-conversion. Phew!

Here’s a picture of the setup:


On the left side there is a circuit consisting of an Arduino and an Attiny85. The Arduino creates a low-frequency ( ‘bass’ ) sine-shaped tone which perfectly sits in the frequency range of the mixer’s bass-EQ. I did some testing here to find the perfect frequency. Testing means: Using Ableton Live to create a white noise, feed this into the mixer, feed the mixer’s output back into Ableton and use the Spectrum-tool to see which frequency gets most influenced by the bass-EQ (C2, that is).

Creating a somewhat true sine needs some effort since the Arduino’s analog outputs only do PWM which isn’t very useful when talking about low-frequency audio signals. PWM basically creates a square-wave signal with a certain pulse-pause relation. While this might be okay for dimming an LED, this becomes quite unusable when dealing with audio because you can simply hear that it’s no sine – the lower the frequency the more the signal turns into some sort of ‘click’-noise. No wonder, the bass-EQ doesn’t influence this to any convience.

That’s why I used this solution to make the Arduino spit out something that’s a little more sinewave-like. I ommitted the circuit as you may see on the picture below. I didn’t have the necessary parts lying around and it worked nevertheless.

The Attiny85 is used to create the second tone. It’s a simple PWM signal at 480 Hz. This time the PWM-nature of the signal can be used for our benefits: A square-wave signal has a recognizable amount of harmonics. You don’t hear one but (at least) two tones. Perfect for us because the mixer I used perfectly influences (well … “perfectly” )  the signals with its mid- and hi-EQs.


The code for the Attiny85 looks like this:

void setup(){
pinMode(3, OUTPUT);

void loop(){

void buzz(int targetPin, long frequency, long length) {
long delayValue = 1000000/frequency/2; // calculate the delay value between transitions
long numCycles = frequency * length/ 1000; // calculate the number of cycles for proper timing
for (long i=0; i < numCycles; i++){ // for the calculated length of time…
digitalWrite(targetPin,HIGH); // write the buzzer pin high to push out the diaphram
delayMicroseconds(delayValue); // wait for the calculated delay value
digitalWrite(targetPin,LOW); // write the buzzer pin low to pull back the diaphram
delayMicroseconds(delayValue); // wait again or the calculated delay value

I guess I found it over here and adapted it to my needs.

the two microcontroller’s output signals are fed into a 7408 (Quad AND) and then sent out into the analog world by a circuit I found over at the MunichMakerLab. This is my first audio-circuit with an Arduino. it’s probably spine-crawling for those who do this on a more professional base but I was getting the best results with this circuit.

[Edit] As someone pointed out in the comments section for this post on Hackaday this might read like I didn’t know at all what I am doing here or that it’s all just a big coincidence. This is not correct. The AND gate protects the audio sources from interfering with each other for a certain amount. I tested that, it simply sounds cleaner. At least I had a certain intention when I added the gates to the circuit (…not that I completely remember….). Looking at the circuit I am still wandering about _why_ but that’s one of the things that I file as ‘Audio things’ for now. [/Edit]



The signal is fed into the mixer and from the mixer sent to another Arduino which does the processing. the circuit looks like this:


To be honest: I cannot really remember where I got this circuit from. Somehow all the solutions I found while trying to find the circuit again look a little different. Again this might be spine.crawling for some of you but… it’s a fun project and it works. The code for the realtime audio-analysis is based on the FHT library by openmusiclabs and expands an example I found over at dontquityourdayjob.

// Easy Customizations

// Adjust the Treshold – what volume should make it light up?
#define THRESHOLD 40
// Attempt to ‘zero out’ noise when line in is ‘quiet’.  You can change this to make some segments more sensitive.
int  oct_bias[] = { 600, 600, 1, 100, 50, 50, 50, 50  };
// Divide Threshold by 2 for top octave? 1 – yes 2 – no.  Makes highest frequency blink more.
#define TOP_OCTAVE_DIVIDE false

// Hard Customizations – know what you are doing, please.
// FHT defaults – don’t change without reading the Open Music Labs documentation at
#define LOG_OUT 0 // use the log output function
#define FHT_N 256 // set to 256 point fht
#define OCTAVE 1
#define OCT_NORM 1

// Delay – defines how many cycles before the lights will update.  OML’s algorithm at 256 samples (needed for our 8 octaves) takes
// 3.18 ms per cycle, so we essentially throw out 14 cycles (I used mechanical relays, you can lower this for solid state relays).
// 15 cycles = 47.7 ms update rate.  Be careful here and don’t change it too quickly!  I warned you!
#define DELAY 15
#include <FHT.h> // include the library
#include <MIDI.h>

void setup() {
Serial.begin(31250); // use the serial port
TIMSK0 = 0; // turn off timer0 for lower jitter
ADCSRA = 0xe5; // set the adc to free running mode
ADMUX = 0x40; // use adc0
DIDR0 = 0x01; // turn off the digital input for adc0

Loop – includes initialization function and the full loop
const int NUMREADINGS=10;
int readings[NUMREADINGS];      // the readings from the analog input
int index = 0;                  // the index of the current reading
int total = 0;                  // the running total
int average = 0;

int bassVal;
int midVal;
int hiVal;

int bassValOld;
int midValOld;
int hiValOld;

const int OUTTHRESHHOLD = 4;

void loop() {
// True full loop
int q = 0;
while(1) { // reduces jitter
cli();  // UDRE interrupt slows this way down on arduino1.0
for (int i = 0 ; i < FHT_N ; i++) { // save 256 samples
while(!(ADCSRA & 0x10)); // wait for adc to be ready
ADCSRA = 0xf5; // restart adc
byte m = ADCL; // fetch adc data
byte j = ADCH;
int k = (j << 8) | m; // form into an int
k -= 0x0200; // form into a signed int
k <<= 6; // form into a 16b signed int
fht_input[i] = k; // put real data into bins
fht_window(); // window the data for better frequency response
fht_reorder(); // reorder the data before doing the fht
fht_run(); // process the data in the fht
fht_mag_octave(); // take the output of the fht

if (q % DELAY == 0) {
// subtract the last reading:
total= total – readings[index];
// read from the sensor:
readings[index] = (fht_oct_out[1] – oct_bias[1]);
// add the reading to the total:
total= total + readings[index];
// advance to the next position in the array:
index = index + 1;

// if we’re at the end of the array…
if (index >= NUMREADINGS)
// …wrap around to the beginning:
index = 0;

// calculate the average:
average = total / NUMREADINGS;

bassVal = average;                                        // : Bass
midVal = fht_oct_out[4] – oct_bias[4];    // Mitte
hiVal = fht_oct_out[7] – oct_bias[7];        //Hochton

bassVal = map(bassVal, -450, -390, 0, 127);
midVal = map(midVal, 9, 107, 0, 127);
hiVal = map(hiVal, -34, 20, 0, 127);

if((bassVal > bassValOld+OUTTHRESHHOLD) || (bassVal < bassValOld-OUTTHRESHHOLD)){
if((bassVal>=0) && (bassVal<=127)){
bassValOld = bassVal;

if((midVal > midValOld+OUTTHRESHHOLD) || (midVal < midValOld-OUTTHRESHHOLD)){
if((midVal>=0) && (midVal<=127)){
midValOld = midVal;

if((hiVal > hiValOld+OUTTHRESHHOLD) || (hiVal < hiValOld-OUTTHRESHHOLD)){
if((hiVal>=0) && (hiVal<=127)){
hiValOld = hiVal;


The whole mechanism is not THAT precise but it gets the job done and it’s a fun thing to watch. The bass-frequency has to be smoothed-out quite a bit in order to make it all work. After spending a little more than a day with this some might ask “what for?”. I tell you what for: for the sake of finally doing it. I had this idea for over a year now and it was well worth trying.

The system is quite slow in its reaction (mainly caused by the necessary smoothing) and results are still a bit unpredictable but turning an audio-mixer into a midi-controller just by using hardware of ~10€ ain’t too bad, isn’t it?


[tube], 720, 540[/tube]

Easy Button USB hack

I guess everybody knows the Staples Easy Button.


There are numerous hacks out in the wild adding some weird functionality to it. For quite some time I wanted to something similar. This is the documentation of how to make the Easy-Button a MIDI-USB device based on Atmega328 (Arduino).

Many hacks have in common that they are either relatively expensive (like…involving something with a dedicated teensy device) or rather ugly (due to holes just being sawed into the Easy Button’s case).

My first goal was to build a device that automatically identifies itself as an HID-compliant USB-MIDI device and gives simple MIDI functionality by using an Atmega328 and V-USB. In order to achieve a correct enumeration and to get a useful starting point I used the demo-versionof USBLyzer to get the necessary data from my KORG nanoKey and altered them in various places (Vendor ID etc..). (You will remember this one later.)

When the button is pressed a ‘MIDI Note ON’ signal is sent. Upon release it sends a ‘Note OFF’ message.

The second goal was to give it a clean overall look.

Let’s see…

This is the Staples Easy Button with the cap and the clicker already being removed (which makes it just a pretty unidentifiable bunch of electronics and some plastic)

we don’t need the speaker so it will be gone soon….

The black line shows how deep the cap goes when it’s pressed.

This is the spot where the USB connector will be placed

I might not be the best craftsman around (already mentioned that once before) but after some filing this one looks pretty decent:

The plastic on the inside has to be cut as well

This DOES look quite well

Now I need to add the circuit board. Due to the speaker being thrown out there is lots of space for that now.

The circuit is basically a 1:1 copy of the V-USB keyboard example. The Button is connected with data pin 6 of the Atmega. It involves some creative soldering of the diodes because I didn’t care too much about the circuit’s layout before I started soldering.

Everything’s coming to an end soon

It seems impossible for my camera to do any decent shots that contain the color red.
Anyway, you might get an idea of how the circuit fits into the structure.

Some detail of how the actual button-mechanism is connected to the Atmega (the blue wires, you guessed it)

To make future additions a little easier I added an ICSP connector which fits nicely into what has formerly been the battery case

Finally… in all its glory.

I had this in the back of my mind for ~2.5 years now. Shortly before starting with this built I started wandering whether this might make sense or be worth the money or time invested or…..

F*CK IT.  Never let doubts get in the way of your creativity.  If this wouldn’t make sense than I probably wouldn’t have built it. Word!   =)

The whole Arduino project (I did that arduino IDE 1.0.3) can be downloaded here. Unzip and copy the folder ‘Nanokey’ to the libraries-folder of your arduino IDE. Feel free to contact me if anything is left unclear.

Adding 24 Buttons to the Numark DJ2GO

Digital Dj’ing has become too clean.


When I was an early adopter of M-Audio’s Torq there were no usable controllers at all (let’s not even think about the xponent, never saw such an ugly piece of plastic).

At first I used a Berhinger BCR together with Bome’s Midi Translator.


Later I built my own Controller specifically taylored for my workflow with Torq. Technically those solutions were far from being perfect, mainly caused my a lack of feedback possibilites of the software and by mechanical imperfections that occur when you build a controller without paying enough attention for the necessary precision.


Nowadays the situation has changed drastically. There’s a huge amount of great Midi controllers out on the market. You only have to plug them in and that’s it. Most of the DVS-packages even come with pre-configured tepmplates ready for you to start dj’ing without any worries.


I don’t like it.


I just can’t help myself but for me digital djing always includes the need and the passion for some amount of own development.

This surely can only be done in an area where errors can occur and you are not a stadium-filling super-paid person, but then … this isn’t djing…that’s a concert.



When I went out making music I normally took this with me.

(yes… a wooden board)

I really like playing around with timecode vinyls. Mixing is pure fun with these things. Unfortunately there is a rather high potential for errors and stepstones. A broken ground wire on a turntable, faulty contact fields for the needle, dirty electricity (when the hot water boiler is in the same circuit as the p.a.  …).  Furthermore Torq’s very own soundcard -the conectiv- is higly prone to errors because of voltage hickups….


There’s absolutely no fun in carrying all this stuff around town just to realize you forgot one fr*ggin cable.

That’s why i tried to slim down my equipment as much as possible.


(Meanwhile I switched to Torq Version 2 and fortunately there are no limitations to using the conectiv (or any other torq hardware) as a dongle for copy protection so I could get rid of this easily.)


I don’t want to stop mixing and beatmatching myself (not using auto-sync or other helpers) but scratching and cutting in most cases is nothing for the places I play music. That’s why I still need some sort of jogwheels but can happily get rid of timecode vinyls.

I could have bought anything like the vci-380 or any common controller with usable jogwheels but even that is too much for me to carry. Leave alone the missing space behind a small bar’s dj ‘booth’.


I came across the Numark dj2go a while ago and gave it a try. And even though it takes some trial-and error the Jogwheels can somehow be used for ‘platter emulation’ (don’t expect too much). Interestingly there are ~zero videos around where the jogdials of the controller are used. Maybe noone really took the time…


Only backdraw of this solution is the fact that the controller is missing a few buttons for the workflow I developed. I’d like to have some buttons to jump to cuepoints, set (and release) loops and maybe trigger a few effects.

On the other hand side the controller has some things I never use since I’m using an external mixer: Channel volume A and B, master- and headphone volume on a midi controller are just unnecessary for me. That’s why I sacrificed them for some buttons.

So, here we go.


The 4 potentiometers on the top half will be exchanged for buttons. This way there are no continous messages of the corresponding CCs any more. Instead every press of a new button will create a somewhat unique CC-vlaue ‘click’ (more on that later). This is done by some simple ladder of resistors. The resistors’ sizes are calculated to fit different needs:

I wanted this to be as simple to rebuild as possible. One resistor for every button should be easy enough.

Furthermore these are the most common resistor values. No problem on getting these anywhere. I also wanted to be on the safe side and select the resistors in a way that the corresponding voltage drops (the midi outputs) are as far away from eacht other as possible. That way the circuit will even work -at least some kind of- stable in rough surroundings (very hot/ cold temperatures that make every resistor change its value to a certain degree).

(All resistors are 5% tolerance.)

The resistors form a simple voltage divider. The supply voltage is 5v. Since everything in the controller is handled with 3.3v the values of the resistors make sure the output voltage never goes above 3.3v (see below).


There is one major disadvantage, however: Simultaneous button-presses will not be able to be realized due to the nature of the construction. Keep this in mind when slaughterig your controller for this.

First up, the case needs to be opened and the poties have to be removed. Avanti warranty! Interestingly, I don’t feel any kind of shiver any more when doing things like this. Voiding the warranty and taking the risk of destroying a basically new and unused controller I just bought seems to be the most normal thing in life. Good. It took me long enough for this =)


The SMD capacitors below the poties don’t have to be removed. I tested the results with the parts being removed and it’s better to keep them soldered. Never soldered SMD before but I got the two caps back in place at 1 o’clock in the night with 2 big glasses of beer in my …headstomach. Seems normal.


Otherwise: If it didn’t want to be treated that a way it shouldn’t have become a Midi-controller. Damnit.


Next the buttons are soldered together. Every potentiometer is exchanged for six buttons. 2 Groups of buttons (12, that is) are fitted onto one stripe of vectorboard. That makes 24 new buttons overall which not only is a somewhat insanely high amount of buttons but which also is the maximum number of buttons that can physically be fitted on top of the controller.



Every button has one pair of contacts which opens and one which closes upon buttonpress. Make sure to get the correct one (the one which closes).



One thing I found out is that the controller uses 3.3 volt internally. To make the voltage drops on the resistors as big as possible I took 5 volts as a supply logic for the buttons. Stole it from a little pin I soldered to the board. The spot is easy to find since it’s situated next to the 3.3v voltage regulator. And because it’s labeled.



As mentioned before the resistorvalues make sure that the maximum output voltage never exceeds 3.3v.

Btw: did you realize the light barriers? This might be the cheapest possible solution ever to easily get some feedback from the jogwheels… should keep this trick in mind for later use.



The case needs a little dremel action for the cables to connect.


And everything needs….hotglue! yeee-haw!



And here we go: 24 shiny new buttons attached to the Numark DJ2GO:



That was the hardware part. Now we have to take care the buttons send useable MIDI-values.

When the original potentiometers were attached every poti sent a continuous stream of CC-values when it was twisted. Now that we exchanged them for buttons we still get CC values when the buttons are pressed. They are, however, not continous any more but somewhat stepped.

There are three problems with this. First up, most DVS systems can’t handle the same Midi-CC for different software-commands. When you map the first button to “cue 1” it will map “CC #8” to it. The difference of the CC value between button 1 and 2 isn’t recognized. That’s why we have to convert different values of the same CC to different MIDI Notes.

Second problem: The buttons are bouncy as hell. Even though I bought the extra-expensive ones to NOT face this problem they create quite some nasty bouncing when pressed and released.

Third problem: the controller’s internal logic seems to do some even-out-processing in this area. This makes sense when poties are attached but isn’t very helpful when we have buttons. Even when the controller gets some perfect bounce-free signal the controller spits out something between 2 and 6(!) CC values.

Problem 2 and 3 make it we have to do some external software debouncing.


Using a Macbook I found Midipipe to be the best tool for the job and wrote a little script for it.

In short: CC values coming from the controller are sent to Midipipe where they are temporarily stored.


In order to debounce (and in order to come across Applescript’s limitation of being single-threaded) a second script is triggered. This script does nothing  more than to wait ~40ms and tell Midipipe to continue by sending it a certain MIDI message back via a dedicated port.


The CC values which came within the last 40ms are then transformed into individual MIDI Notes and sent out via the IAC MIDI port into the software.


Both scripts are a little buggy still and need some fixing.They will be made available soon. Contact me if you urgently need them.

The whole system is far away from being perfect. Sometimes the buttons don’t become recognized … but  … that’s great – somehow. Adds some flavour. At least everyone will otice I’m not using auto-sync when things are messed up.

I love this.



There has been some progress, lately. First up when I visited my parents I used my father’s toolshed to build some case out of plywood in order to be able to transport the controller without breaking it:



Secondly, I was out making music with it for the first time outside my home. This took place at the Freundlich & Kompetent in Hamburg.

And as expected the controller failed BIG TIME. Somehow there was lots of electrical shizzle around and the modified Numark controller seemed to catch it all. Showing this in the loop section for ‘Deck A’ behaving totally random without even touching the device or any of the cables around.

Well, I deactivated this function in the Midi-Editor and went without it that night. Not a big problem (The night was great, by the way…The bar has a super nice crew).

Back home I did some deeper investigation and after applying an insane amount of hotglue I realized that my midnight soldering skills (after some beer…see above) seem to have left me. One of the wires connecting the buttons to the contacts of the former poties was quite sensitive to impact. Midi data were created upon … breathing onto it… I guess that relates to one of the SMD caps I temporarilly desoldered for testing purposes got killed.

So … after a heavy research I made an educated guess and then took the first thing that came into line of sight and added an extra capacitor (47 nf for those who care) and … everything seems to be perfect now.


You can even see it after the enclosure has been put back together =)


The buttons are now a little more sturdy as well due to an improved construction of leftovers from various vectorboards. Everything is hot-glued, of course =)


Anyways, this is the current configuration I use (same for ‘Deck B’). I will post a video of this together with the current version of the Midipipe-script soon.





Oh man ….

to make things short: even after adding a new capacitor I experienced a faulty behaviour from time to time. This resulted in ‘phantom button presses’ (a loop or a que was triggered without touching the device) preferrably in situations when it was very hot and/or humid around. Looking at the circuit diagram above it becomes clear why: The circuit was always closed in some way. Current was flowing the hole time. Everything that might have caused even little changes in the resistors’ values (temperature being one of these things) MUST have caused a changed current and therefore some ‘phantom’ action.

Looking back that seemed to be the perfect circuit to provoke such a behaviour. Might keep this in mind for later use …

As soon as I realized that i built an … improvable … thing it became clear to me that I had to change the circuit. The new circuit now only causes current to flow when any of the buttons are actually pressed and furthermore widens the range of values that are created when a button is pressed. That way I could change the midipipe script to use a wider hysteresis to make operation even more reliable:


Putting it all back together I found a new way of fixing the buttons to the controller. I used scrap parts of vector board for this before but toothpicks do a much better job in my eyes


Looking as good as new from the store


[Update 10.11.2013]

The controller works like a charm now. There are only little things left to improve. One of the things is to make sure I’m not pressing the wrong button when using it without watching. So I added this little piece of plastic. (the one between the black and yellow buttons.) Doesn’t sound too impressive but it really helps preventing wrong button presses since my fingers ‘know’ where they are.



Simple A$$ DMX Over MIDI Expander


(a picture of a blue box….NOW I’ve seen it all)



As you already might have guessed this is a simple MIDI to DMX transceiver. It’s powered via USB and doesn’t need any additional drivers. On a German Windows XP it installs itself as an ‘USB Audiogerät’.

The aim of it is to have some practical solution to control lights with Ableton (any midi sequencer). In Germany we say “AEG: Auspacken, einschalten, geht” (which is a pun based on a german company’s name and means something like “unpack, switch on, enjoy”.)

There are, of course, other ways to control your lights via a midi sequencer. You could, for example, have a dedicated midi track in ableton to send out midi to your GrandMA onPC (any lighting software). This would give you the power of your lighting desk combined with the power of your midi sequencer.

On the other hand side this might be a little bit of overkill if you just want to drive some LED pars (or it might even be impossible if you never worked with a lighting software before). Furthermore you are always using your lighting software ‘blindsided’. you can just hope your midi clip triggers the correct chaser. I know from my experience that it really takes a lot of preparation to make sure every midi clip only triggers your desired lights. Many things can (and will) go wrong. Therefore it’s easy (and fun – somehow) to quickly edit your midi clip on your light-track (or group of tracks) and instantly see the changes you made. Don’t forget: If you are using midi clips you are automatically in sync with your sequencer. No need to send an extra clock signal etc.

However, you could also think about controlling your existing hardware lighting console via true DMX. Might lead to some interesting combinations if you are having a gig in a venue with a fixed lighting structure and a lightjockey who will give you control over his desk (as if that ever happened……).


Sadomex can send out DMX-signals based on incoming midi-notes or midi-CCs. The mode can be changed during usage. The communication works one way. It’s midi IN and DMX OUT.

512 DMX channels are supported. This is achieved by using different midi channels. Midi Notes/CCs 0-127 on channel 1 represent DMX channels 1-128. Midi Note/CC 0 (the first one….however you may count) on midi channel 2 represents DMX channel 129 and so on….

Naturally, the resolution is only half as precise as native DMX since midi only supports a range of 128 values and DMX supports 256. There could be different workarounds but that would only make it more complicated. This way, a midi note’s velocity of 127 (full) represents a DMX channel’s value if 255.


This video shows the device in action with an LED Par lamp. Notice how the lights stay in sync with the metronome:



This is how you configure Ableton to talk to Sadomex. In this scenario the first 128 DMX channels can be addressed due to the output channel being set to 1. If you would like to control a fixture with a start-address greater than 128 (and smaller than 256) you would set the output channel to 2. Realize Ableton’s possibilities to group tracks. This way vou could control a whole bunch of fixtures as if they were midi clips. The clips in the screenshot, by the way, are those from the video above.



A demo file for Ableton 8.2 can be downloaded here . It shows some basic patterns for controlling an RGB LED Par at DMX address 10.


I put together another example which is a little more complex. This one controls a Coemar iSpot 575 EB with a base address of 194. Notice how the output midi-channel of the iSpot’s tracks is set two ‘2’ in order to reach DMX-address 194. The pinkish coloured clips are chasers (e.g. continuously change colourwheel 2 between colour 5 and 6) whereas the blueish-green ones represent static values (gobowheel 1 set to ‘open’).


This is all done with Sadomex being in ‘Note’ mode (reacting to Midi notes and their respective velocity values…).In my eyes, Ableton’s workflow is not quite optimized for easily creating CC curves for this special scenario. Maybe it’s easy to achieve in-sync CC curves/values with other sequencers.

It surely IS a pain in the back to put together pan/tilt motion with midi notes. Furthermore you are really bound to a certain tempo when it comes to pan / tilt motion (a smooth tilt wave at 112 bpm like shown in the example won’t look as smooth at 65 bpm without being altered to a high degree).  On the other hand side it’s fun thinking about what you might be able to do with things like Ableton’s built in Midi Effects like Velocity, etc….


This time it’s being controlled via Akai’s APC20 which makes it even more fun.

Due to my 1337 computer skillz (not) it was absolutely impossible for me to convert my video -with- audio. If you look carefully you see the LED Par from the previous example in the bottom of the movie. It’s flashing in sync. At least you can get an idea of what it’s all about:


You can download the second example file here .


I’m not quite sure how to proceed with this right now. At the moment (october 2010) all my resources are tied to other things. Maybe I’m going to build a few ones when there is time and sell or swap them. Contact me if you are interested in a unit or if you have any questions regarding the device.


[Update 31.10.2010]

Oh Ableton how much I adore love like you! After playing with the above setup for a time I was not really confident with Ableton’s native possibilities for live-editing the Midi (i.e. DMX) output. For example: It’s a quite common task to make a moving head point to a certain position and make it do its motion arround this position then. This can basically all be done by simple note-to-dmx conversion but it’s not as dynamically assignable and  easy to do like you would with your dedicated lighting-controller (I guess you know I’m talking ’bout GrandMA…….). That’s why I had a look at Max 4 Live. Fortunately I have been tinkering with PureData before so the start was not that complicated for me. What came out is a nice little MAX midi effect doing all the necessary processing within one device:


(I later realized that what I built is nothing more than an ordinary MIDI-lfo.) What the effect does is that it creates a sine-envelope for the velocity values of the incoming notes (those notes which are played in the active clip). Since everything is midi-assignable the amplitude of the sine (= the size of the effect) and the offset (= the position the head is moving around) can either be selected from fixed and user-configurable presets or they can directly be controlled by a knob or a fader (assigned to the dials in the screenshot). The sine’s periodicity (=fixed multiples of the motion’s velocity) can be selected from four presets as well.

(Yes…you surely Do have to look a little bit careful to locate the mouse and its actions in the lower left corner of Ableton…)



See how the Pan/ Tilt positions can be selected by triggering one of the presets or how they can be controlled by the dial.



The output still looks a little …not perfect but I don’t care. It does the job quite well. One of the biggest advantages: It doesn’t send a ‘Note OFF’ when live’s transport is stopped. That leads to the fact that the last position is stored and the moving head does NOT reset to it’s ‘zero-position’. Good thing just in case you are in the middle of a show and need to stop live’s transport. Sure it’s a good idea to have those kind of effect on the dimmer channels too because that way lights will stay on even if you stop.

The video below shows this behaviour quite well.



You can, as well, apply the Max4Live device (which doesn’t have an interesting name yet) to other channels. The colour wheel, for instance. The result is the same: You can select colours from one of the presets or apply a colour chaser or controll the position of the colour-wheel in realtime via the midi-assignable dial.