Update May, 13: Disqus reenabled

Disqus has been updated to conform to the GDPR regulations so that it could be reenabled on this site.

One thing that I found missing compared to the X32 is the ability to record 2 channels directly to a usb stick. Therefore I thought about possible ways to work around this missing feature. In the end I settled on a Raspberry Pi 3 which is running the audio player distribution moode audio and is connected via USB to the XR18. With a small bash script it is possible to create an automatic recorder that will record mp3 files whenever audio is playing on the XR18.

Let’s start with some pointers on setting up the XR18 for moode audio and recording. Make sure to send the Main LR bus on USB1 and USB2. So go to In/Out, select USB Sends and select Main LR for USB1 and USB2. You can choose any mode you like but I prefer Pre EQ. My Main LR EQ is always trimmed for the room. So I don’t want to have this EQ on the recording. The Pre EQ setting will achieve just that and has the added benefit that changes to the master volume will also not be reflected on the recording. The screen will look like this:

USB return channels 1 and 2 also need to be mapped to XR18 channels. I usually map them to Aux L/R and FX4 L/R. I only need 3 send FX, so my FX4 is configured as an insert effect and therefore does not need return channels. By mapping the USB return to FX4 L/R, I free up the Aux Stereo Channel for other uses. This is what my USB Returns mapping looks like:

In moode audio you just need to enable USB audio output and you will be able to play audio through your XR18 without any other configuration changes.

Now we are all set for working on the recording side. The following steps can be done on a plain Raspbian distribution or on moode audio or most probably any other Debian based Rapsberry Pi distribution.

First we need to install required software packages. So log in to your Raspberry via SSH and run this command:

sudo apt-get install sox libsox-fmt-mp3

Now create a new shell script named recorder.sh in /home/pi with the following contents:

#!/bin/bash

while [ 1 ]
do
  FILENAME=/media/FILES/XR18/$(date +"%Y%m%d_%H%M").mp3
  AUDIODEV="hw:X18XR18,0" rec -q --buffer 262144 -c 2 -C 256 $FILENAME silence 1 0.1 2% 1 3:00 2% gain -9
  [ $? -eq 0 ] || exit $?
  
  # Remove file if nothing has been recorded
  FILESIZE=$(du -sb $FILENAME | cut -f 1)
  if [ $SIZE -lt 2048 ]; then
    rm $FILENAME
  fi
  
  sleep 30
done

Please change the path in FILENAME to the location where you want the recordings to be stored. I am using a USB stick named FILES that is automatically mounted during bootup by moode audio under the path /media/FILES. On this stick the recordings should be stored in the directory XR18.

The XR18 will identify itself to the operating system with the string X18XR18. If you are using another device, you need to identify the string that the other device reports by running aplay -l. The X32 for example can be accessed by the name XUSB.

The recording is done in an endless loop with the current timestamp as the filename by running the rec utility. It is configured to start recording once a signal with at least 2% volume is present and it will automatically stop 3 minutes after the signal level has dropped below 2%. Additionally the gain is reduced by 9dB to prevent possible clipping when running the XR18 output hot. Recording format is mp3 with a bitrate of 256kBit.

Should the rec utility exit with an error code (for example if the XR18 is not found), then the script will terminate. In all other cases it will delete the created file if it has not recorded anything (detected by checking the file size), sleep for 30 seconds and then start the recording again.

Make the script executable by running:

chmod a+x recorder.sh

Now you only need to run this script automatically after booting up the Raspberry PI. Do this by appending the following line to the file /etc/rc.local before exit 0:

/home/pi/recorder.sh &

From now on, you just need to connect your Raspberry Pi via USB to the XR18 and it will both serve as an audio player and a recorder that will start recording whenever a signal is detected on the Main LR output of the XR18.

Update March, 5: Multitrack Recording

It is also possible to use the rec utility for multitrack recording. It is possible to record all 18 inputs of the XR18 in a single multichannel WAV file. But there are some caveats you need to be aware of:

• Silence detection does not work in multitrack mode. So you need a way to start and stop the recording manually.
• Multitrack files tend to get very big, so your recording target (USB stick) needs to be formatted with a file system, that supports large files. I had no problems with exFAT formatted USB sticks.
• Your USB stick should be able to consistently write at least 2MB per second. I had some good results with a SanDisk Ultra Fit 64GB USB3 stick.

Here is the command line to record 18 tracks 24bit WAV files:

AUDIODEV="hw:X18XR18,0" rec -q --buffer 262144 -c 18 -b 24 /path/to/file.wav

Update May, 12: 2-Track WAV Recording

I have now switched to recording wav files as my USB sticks have more than enough free space so that I don’t need compression during recording. The rec parameters look like this:

AUDIODEV="hw:X18XR18,0" rec -q --buffer 1048576 -b 16 -c 2 ${FILENAME} silence 1 0.1 0.1% 1 3:00 0.1%

Update June, 2: Fixing soundcard order

With the latest Moode release 4.1 the XR18 sometimes is detected as device 0 and sometimes as device 1. This leads to problems when trying to use Moode. The sound will not play. You can see the order your cards have been initializes with:

pi@moode:~ cat /proc/asound/cards
 0 [ALSA           ]: bcm2835_alsa - bcm2835 ALSA
                      bcm2835 ALSA
 1 [X18XR18        ]: USB-Audio - X18/XR18
                      BEHRINGER X18/XR18 at usb-3f980000.usb-1.3, high speed

Moode expects the USB device to be device 1. To make sure the XR18 is device 1 you need to create a file /etc/modprobe.d/alsa.conf with the following contents:

options snd-usb-audio index=1

Besides the XR18, I have also connected a X-TOUCH-MINI controller which is also recognized as an USB audio device, so I need to make sure the XR18 is device 1 and the X-TOUCH device 2. This is done with the following line:

options snd-usb-audio index=1,2 vid=0x1397,0x1397 pid=0x00d4,0x00b3

The controller is based on a cheap Arduino Nano board that can be ordered on Ebay for around 3 Euro. All parts can be bought for less than 10 Euro in total. Here is a complete list of all necessary parts (assuming that you want to connect an existing footswitch):

• Arduino Nano
• 5-pin DIN jack
• 6.3mm Instrument cable jack
• LED in your color of choice
• 2 220 Ohm resistors
• Some wires
• small case

Wiring is pretty easy. Here is a complete view of the breadboard layout:

To connect the footswitch, wire the tip of the 6.3mm jack to pin D2 on the Arduino. Connect the ring to pin GND.

Connecting the MIDI jack is done by soldering a 220 Ohm resistor to pin 4 and then connecting the other pin of the resistor to pin 5V on the Arduino. Pin 2 on the jack needs to be connected to GND and pin 5 to TX1. Here is a picture of the wiring on the MIDI jack:

The LED is optional but I wanted a visual indicator when I have mute enganged on the X32. Solder a 220 Ohm resistor to the longer pin of the LED and connect it to D12 on the Arduino. Now connect the other pin of the LED to GND. Here is the wiring on the breadboard:

Finally a view of all pins used on the Arduino:

The hardware part is now complete. All you need to do is upload the following program to the Arduino board:

// pin to use for indicator LED
int ledPin = 12;
// pin that is connected to the footswitch
int buttonPin = 2;

int buttonState = 0;
int buttonLastState = 0;
int buttonInitState = 0;

int muteStatus = 0;

void setup() {
  pinMode(ledPin, OUTPUT);
  pinMode(buttonPin, INPUT_PULLUP);
  
  // Setup serial port for MIDI communication
  Serial.begin(31250);
  
  // read current button state, a press is detected whenever
  // state changes to anything else than the init state
  buttonInitState = digitalRead(buttonPin);
  // we only want to do something on state changes
  buttonLastState = buttonInitState;
}

void loop() {
  buttonState = digitalRead(buttonPin);
  
  // has the state changed?
  if (buttonState != buttonLastState) {
    buttonLastState = buttonState;
    if (buttonState != buttonInitState) {
      // button is in pressed state, trigger action
      if (muteStatus == 0) {
        // mute and light up LED
        digitalWrite(ledPin, HIGH);
        // send CC 85 on channel 2 with value 0 to mute
        // mute group 6 on a Behringer X32
        midiCc(2, 85, 0);
        muteStatus = 1;
      } else {
        // unmute and turn off LED
        digitalWrite(ledPin, LOW);
        midiCc(2, 85, 127);
        muteStatus = 0;
      }
    }
    // workaround to prevent fluttering of button state
    delay(10);
  }
}

void midiCc(int channel, int command, int value) {
  Serial.write(175 + channel);
  Serial.write(command);
  Serial.write(value);
}

This solution should work with any regular footswitch. Polarity doesn’t matter as the initial state will be detected during startup. I am sending MIDI CC messages to mute and unmute mute group 6 of the X32 in this example, but you can replace that part with any MIDI command you like.

If you followed my other articles on how to install a mail server on Ubuntu, you have a running Dovecot server. You also need a running Apache server with PHP5. The server has to respond to https requests. If your server meets these requirements, adding Z-Push to this setup is easy.

Download the latest Z-Push version from here. At the time of writing the most recent version is 2.1.0.

Now install necessary Ubuntu packages:

aptitude install php5-cli php5-imap php-soap

Unpack Z-Push and move the folder into your https directory:

tar -xvzf z-push-2.1.0-1750.tar.gz
mv z-push-2.1.0-1750 /var/www/vhosts/YOUR_DOMAIN/httpsdocs/z-push
chown -R www-data.www-data /var/www/vhosts/YOUR_DOMAIN/httpsdocs/z-push

Z-Push needs two additional working directories:

mkdir /var/lib/z-push /var/log/z-push
chown www-data.www-data /var/lib/z-push /var/log/z-push

Now it’s time to modify the Z-Push configuration file config.php. You only need to set the timezone and the backend provider. Anything else can be left on default.

define('TIMEZONE', 'Europe/Berlin');
define('BACKEND_PROVIDER', 'BackendIMAP');

The last step is to set an alias address to the z-push folder in the Apache virtual host configuration:

Alias /Microsoft-Server-ActiveSync /var/www/vhosts/YOUR_DOMAIN/httpsdocs/z-push/index.php

You can test if the server is setup properly by opening the url https://YOUR_DOMAIN/Microsoft-Server-ActiveSync in the browser. You will be prompted for username and password. After you enter your login credentials, the server will answer GET not supported. If you get this message, you are all setup.

On the iPhone you now have to create a new Exchange mail account and you are done.

One HDD is dedicated as a backup drive. Every computer is backed up via Time Machine on this drive. The other HDD is used for network shares. Important documents, pictures, whatever are stored on a dedicated documents share on that HDD. This share is also backed up daily onto the backup drive.

Once per week I connect a USB drive to the NAS and create a backup of the backup drive.

With this strategy I feel quite confident that hardware failures or human failures will not cause any data loss. The only scenario missing so far is fire / theft / water damage. Anything that will affect all HDDs in my household at the same time.

This is where offsite backups come into place. The Synology NAS has different options for creating offsite backups. You can use Amazon S3, Amazon Glacier, Strato HiDrive or any server running a rsync daemon. All of these options have the problem that backups are not being encrypted before they are sent to the destination. I don’t want to store my data in unencrypted form anywhere on the internet.

Luckily it is possible to create encrypted shared folders on the NAS. Synology uses ecryptfs to encrypt files stored on this folder. So I am using an encrypted folder on the backup drive to store the unencrypted documents folder from the first HDD. The files are encrypted using a passphrase. Make sure that you use a secure und sufficiently long passphrase. Also make sure that you do not loose this passphrase. Without the passphrase you will not be able to decrypt your files.

When backing up the encrypted folder only the already encrypted files are sent to the destination server. Filenames and folder names are also encrypted so that the data is completely secure as long as the passphrase is long enough.

I already have a virtual server hosted by a reliable company which has enough diskspace and gets backed up daily. So I decided to store my offsite backup on this server. This is done via rsync. Unfortunately Synology does not support rsync over SSH so you need to setup an rsync daemon. The following steps describe how to setup this daemon in a secure way on Ubuntu Linux.

First you need to install rsync:

sudo aptitude install rsync

Now create the configuration file /etc/rsyncd.conf with the following contents:

max connections = 2
log file = /var/log/rsync.log
timeout = 300

[SHARE_NAME]
path = SHARE_PATH
read only = no
list = yes
uid = SHARE_USER
gid = SHARE_GROUP
auth users = LOGIN_NAME
secrets file = /etc/rsyncd.secrets
use chroot = yes

Replace SHARE_NAME with any symbolic name you like. You need to specify the share name when setting up the remote backup on the Synology NAS. The SHARE_PATH should point to a directory on the server where you want to store the backup. Uid and Gid should point to a user account that has write privileges to the destination directory. LOGIN_NAME is only used for authenticating against the rsync daemon. You don’t need to specify a system user.

The login credentials are specified in the file /etc/rsyncd.secrets. Create this file and add the LOGIN_NAME specified in /etc/rsyncd.conf:

LOGIN_NAME:PASSWORD

Again, use a long and secure password.

Please note that rsync uses unencrypted file transfers. Never use the rsync daemon to transfer unencrypted private files over the internet.

Now you need to activate the rsync daemon. First set RSYNC_ENABLE=true in /etc/default/rsync. Now you can start the daemon:

sudo /etc/init.d/rsync start

I recommend preventing brute force attacks on the rsync daemon via fail2ban. Please see my article Securing SSH server with fail2ban on how to setup fail2ban. You can use the following ruleset to catch all login attempts:

failregex = unknown module.*\(<HOST>\)
            auth failed on module.*\(<HOST>\)

Every IP address with 4 failed login attempts within 10 minutes will be blocked for a couple of hours. Together with a secure password this will effectively prevent break in attempts.

The rsync log files can become quite large. You therefore need to setup a logrotate job. Create the file /etc/logrotate.d/rsync with following contents:

/var/log/rsync.log {
    daily
    rotate 4
    compress
    notifempty
    missingok
}

Everything is now setup on the server side. You only need to create the backup job on the Synology NAS and don’t forget to select the encrypted folder as the source folder.

The problem is that the images have not enough contrast to be easily readable on screen. Text is usually grey instead of black and you always see a grayish paper background.

Here comes ImageMagick to the rescue. You can easily stretch the color distribution so that light gray becomes white and dark gray becomes black. I use the following command line to modify all images in a folder before converting them to the PDF format:

for img in *.jpg; do mogrify -normalize -level 10%,90% -sharpen 0x1 $img; done

The level values fit my requirements. You should try different values if you don’t like the result.

Please note that pictures will look worse after the above step. Text documents will improve but the colors might change a bit.

To make the DMX interface work, I needed to update the Raspberry kernel as the preinstalled kernel had some issues with the DMX interface. Kernel updates are easy using the rpi-update script from Hexxeh: https://github.com/Hexxeh/rpi-update

Once everything was working, I tried to run the Raspberry Pi standalone without a network. This is the scenario on stage. Only the Raspberry Pi connected to the light fixtures via DMX. In this scenario OLA refused to start because it was searching for a network interface and ignoring the loopback interface.

A simple workaround is to configure a static ip address for eth0. But then you can no longer use DHCP when connecting to your normal network.

To keep DHCP capabilities and provide a backup network interface when the Raspberry Pi is not connected to a real network, I added a new virtual network interface with a static ip address.

Edit the file /etc/network/interfaces and add the following lines:

auto eth0:0
iface eth0:0 inet static
address 10.1.1.100
gateway 10.1.1.1
netmask 255.255.255.0
broadcast 10.1.1.255

The above configuration will create a new virtual interface eth0:0 with a static ip address. Make sure that this address is not conflicting with your network.

Now OLA will start without issues even if it is not connected to a network. On stage, I just plug in the Raspberry Pi and once it is booted I can playback scenes via a small USB keypad. No display and no network needed.

Filtering is done in the final mail delivery stage. Normally Postfix will write the messages directly into the Maildir of the user. We need to change the Postfix setting to use the Dovecot delivery agent. Edit the file /etc/postfix/main.cf and add the following line:

mailbox_command = /usr/lib/dovecot/deliver

After a restart, Postfix will forward received messages to Dovecot for delivery:

sudo /etc/init.d/postfix reload

The deliver tool uses the configuration file /etc/dovecot/dovecot.conf. Make sure that this file is globally readable:

sudo chmod 644 /etc/dovecot/dovecot.conf

Now we need to edit the file /etc/dovecot/dovecot.conf and enable sieve and managesieve functionality. First enable the managesieve protocol. Search the line with the protocols entry and add managesieve as a new protocol:

protocols = imap imaps pop3 pop3s managesieve

Now make sure that the section lda is enabled and contains the following settings:

protocol lda {
  postmaster_address = postmaster@yourdomain.com
  mail_plugins = sieve
}

Set the path to your sieve scripts in the plugin section:

sieve=~/.dovecot.sieve
sieve_dir=~/sieve

You can now restart Dovecot:

sudo /etc/init.d/dovecot restart

Server side mail filterin should now be working. You can test it by setting up some rules. I would recommend to use a webmail client like Roundcube to do this. Roundcube has a very nice client plugin for the managesieve protocol.

I want to use the current version of nginx, so I use the PPA repository where current nginx builds can be found:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:nginx/stable
sudo apt-get update
sudo apt-get install nginx

Currently this will install nginx version 1.2.0. Now install the packages required for php:

sudo apt-get install php5-cgi

Now we need to create a start/stop script to start our cgi process. Create a file /etc/init.d/php-fastcgi with the following contents:

#!/bin/sh

USER=www-data
CHILDREN=3
MAX_REQUESTS=1000
RETVAL=0

start() {
    echo -n "Starting PHP FastCGI: "
    start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- - USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$CHILDREN PHP_FCGI_MAX_REQUESTS=$MAX_REQUESTS /usr/bin/php-cgi -b 127.0.0.1:9000
    RETVAL=$?
    echo "OK"
}

stop() {
    echo -n "Stopping PHP FastCGI: "
    killall -q -w -u $USER /usr/bin/php-cgi
    RETVAL=$?
    echo "OK"
}

case "$1" in
    start)
        start
    ;;
    stop)
        stop
    ;;
    restart)
        stop
        start
    ;;
    *)
        echo "Usage: php-fastcgi {start|stop|restart}"
        exit 1
    ;;
esac

exit $RETVAL

This script will start 3 PHP worker processes which will server up to 1000 requests each. Make the script executable:

sudo chmod a+x /etc/init.d/php-fastcgi

Now you can try to start the php daemon:

sudo /etc/init.d/php-fastcgi start

You should see the daemons in the process list. If everything is running so far, enable autostart for the service:

sudo update-rc.d php-fastcgi defaults

The next step is to create a self signed SSL certificate:

openssl req -new -x509 -days 4312 -nodes -keyout /etc/nginx/web.pem -out /etc/nginx/web.pem

When filling out the certificate details, make sure that you enter your domain name in the field “Common Name”. The above command will create a self signed certificate file.

The last step is to create virtual host configurations for nginx. Here is an example which can act as a boilerplate to setting up a new vhost which will listen on http and https. Let’s say we want to create a vhost for a domain mydomain.com where the files are located at /srv/www/vhosts/mydomain.com/httpdocs. Create a new file /etc/nginx/sites-available/mydomain.com with the following contents:

server {
    listen 80;
    listen 443 ssl;
    server_name mydomain.com www.mydomain.com;
 
    ssl_certificate /etc/nginx/web.pem;
    ssl_certificate_key /etc/nginx/web.pem;
  
    access_log /srv/www/vhosts/mydomain.com/logs/access.log combined;
    error_log /srv/www/vhosts/mydomain.com/logs/error.log;

    root /srv/www/vhosts/mydomain.com/httpdocs;

    index index.php;

    location / {
        try_files $uri $uri/ /index.php;
    }

    location ~ \.php {
        try_files $uri = 404;
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass 127.0.0.1:9000;
    }
}

If you want to redirect all non-ssl traffic to the https port, add the following lines inside the server block:

if ($ssl_protocol = "") {
   rewrite ^ https://$server_name$request_uri? permanent;
}

To activate the vhost, create a symbolic link in the directory /etc/nginx/sites-enabled/:

ln -s /etc/nginx/sites-available/mydomain.com /etc/nginx/sites-enabled/mydomain.com

And now reload the nginx configuration:

sudo /etc/init.d/nginx reload

Everything should be working by now.

sudo defaults write /System/Library/LaunchDaemons/com.apple.backupd-auto.plist StartInterval -int 14400

You can restore the default interval with:

sudo defaults write /System/Library/LaunchDaemons/com.apple.backupd-auto.plist StartInterval -int 3600