Monthy Report 2023 / 05


It has been quite some time since our last monthly report, approximately a year or so. However, we believe it’s important to provide an update considering the significant developments that have occurred since then. So, let’s have a discussion and incorporate our recent discoveries and experiments into this article, embracing our role as enthusiastic coders.

Before we proceed, we want to emphasize that we welcome any questions or feedback through various channels, including our contact form and YouTube. We encourage you to share your own experiences as well.

The primary focus of this article will revolve around hardware and its significance in our work. Let’s begin with a brief introduction discussing our perspective on this subject. When we established CRASH SERVER, one of our core objectives was to have a portable setup that would facilitate travel by train. We were determined to rely solely on backpacks, avoiding the need for transportation by car. The idea was to enable on-the-go coding!

In many instances, we can even perform live coding  riding our bikes. true stuff. In theory :). Another consideration we had was the ability to set up quickly upon reaching a destination. We aimed for a setup time of just 15 minutes for a complete configuration, or even a few minutes for a more streamlined one.

Our setup can be as minimal as two laptops, such as when we perform live gigs between DJ sets. In such cases, we forgo visuals and lights, focusing purely on the essence of live coding. On the other hand, we can also create a more elaborate setup that remains lightweight enough for two tech enthusiasts to carry around. Now, let’s delve into the specifics of the four types of setups we employ. Although these are general considerations, they can be customized to accommodate any given situation. Following that, we will discuss the particular hardware we have developed and utilize.


The relationship between hardware and software is inherently interconnected.

Recently, my colleague and I made a transition from Ubuntu Studio to Arch. While he opted for MANJARO, I decided to take a leap and switch to ENDEVOUR OS. We encountered various challenges along the way—just a small list of issues that can arise and consume hours of debugging. And these are only a few examples; there are countless others. It’s important to be aware that even seemingly insignificant changes to your setup can have significant repercussions.

Some of the challenges we faced included:

  • Migrating from Python version X to version Y
  • Forgetting to fully plug in an RJ45 cable
  • Discovering that the operating system’s default firewall blocks certain local area network packages
  • Forgetting to create an empty doc in order for our foxDot fork to work
  • Misplacing a small adapter (yes, XLR 3 to 5 pins, we’re looking at you)
  • Experiencing sound card issues due to a system update that switched on Wayland
  • Neglecting to enable the hold function for debugging the KP3 midiInA
  • and so many more.

Introducing new hardware and software bring you quickly to developpement hell. When your goal if to code music and have a good time, spending hours on those subject can be quite a challenge to overcome.
Recently we’ve decided to have a jam session before anything else in order to always enjoy our sessions. Debugging should be done after the pleasure of playing and experimenting.

At times, we found ourselves in rather tricky situations. Tasks that should be straightforward often introduced a plethora of difficulties. Naturally, one desires a seamless experience where everything works smoothly and efficiently. After all, the ultimate goal is to enjoy the process.



[1] Setup up 1 : Foundation.


In order to adapt to various venues and gain control over volume, as well as benefit from lower latency compared to the integrated sound card, we utilize an external sound interface. Currently, we rely on the Behringer UA 404, a cost-effective 4×4 interface that gets the job done. It allows us to output audio through XLR, jack 6.3, and RCA connections. We have also experimented with a Focusrite interface for a few months. Setting up this configuration is fairly straightforward; we simply need to configure our network to use fixed IP addresses, and we’re ready to go after routing everything through Carla.

[2] The classic live-coding setup.

Similar to the previous setup, we continue to use an external audio interface and connect two laptops. However, this time we have added video output to display our live-coded code. To ensure readiness for various venues with different setups, we have been traveling with a few essential accessories for a few months. These include an HDMI-VGA adapter, a small HDMI cable, a 2 HDMI splitter, and several other converters. I always carry more adapters than necessary, just to be prepared for any situation. Additionally, if the gig is in close proximity, I bring a 25-meter VGA cable to accommodate a projector that may be farther than initially planned. We own two projectors, which emit approximately 3500 lumens, suitable for small to medium-sized venues. They are lightweight and accept standard inputs, including Wi-Fi connectivity. Currently, we are capable of outputting three full HD video streams in addition to our laptop screens, although such a requirement or option rarely arises, but we’d love to explore those possibilites much more, especially concerning video mapping as we have the know-how on that matter – still, question of venue.


[3]. Modular setup from simple to complex

Building upon the previous setups, let’s enhance the light, sound, and interaction features.

For a period of time, we incorporated effects pedals into our setup, connecting them to our UA 404 audio interface. There is a tutorial available [here] that explains how to integrate these pedals with FoxDot. Specifically, we utilized guitar/bass distortion pedals, typically two of them, along with reverb and delay pedals connected to separate outputs. However, we have recently made a transition to the [ModDwarf], a compact fx pedal/mini computer that serves as a amazingly versatile effects pedal. We also introduced recently a Kaoss Pad 3 to do some looping, feedback and synths, controlled by midi & osc.

When we go all out with CRASH SERVER, we introduce additional elements, although not necessarily all of them. These elements include:

  • The ENTTEC USB PRO DMX controller and lights: Through our Open Framework program, we send messages to the ENTTEC USB controller. Depending on the current scene, we trigger various lighting effects, sync to sound.

  • Usually we travel with 2 LED pars. They provide some powerfull lights for a small/medium venue and are of course reactive to our show in many ways.

  • We also use led strips (usually about 10m, sometimes more) with each led controllable via arduino.
    Depending on the state of the server and triggered at each code evaluation by any of us, they provide a visual feedback to our coding. Each code we write sends a message from one end of the strip to the center area.
    The center area then responds by getting more excited (red light pulse) depending on the CPU level.

  • The Crash Converter: This is an accompanying device that enhances our setup, working in conjunction with the Big Red button and our led strips. A custom made hardware element that allow for power inputs to LEDs, arduino control & usb.

Crash server live

The Big Red Button.

We have always placed great importance on interacting with the audience. The concept of the big red button has always fascinated us—a grand, magical button capable of activating or deactivating the “server” on demand. While we may delve into a detailed explanation of the entire server concept in the future, in essence, it introduces a third player into our Troop/FoxDot session. This player can write code, evaluate it, and create music using samples, synths, or loops. They also have the ability to modify our own code, injecting a significant level of chaos into our live session. They can alter scales, adjust BPM, or manipulate any parameter we wish to expose. The big red button also communicates with our CRASH/OS app, which is based on the Open Frameworks platform, triggering a special mode that alters visuals and the user interface.

While we used to be the ones triggering the button ourselves, nowadays we occasionally invite the audience to activate the server. It adds an element of surprise and collaboration, allowing them to participate in our performance.

Mod Dwarf

Recently we’ve introduced the Mod Dwarf pedal []
It’s a very versatile sound device that can be used in standalone pedal or controlled by midi, osc and whatnot. At this moment it replaces our guitare pedals we used.
We’re still adding functions to control the board by osc for example. We’re chaining the moddwarf with the kaoss pad III using a usb connection. 
> At this point anyways, this fx pedal is really quite amazing, the signal routing system is suprisingly versatile.

At some point we’ll make a thorough article on the pedal, don’t worry 🙂


Kaoss pad III

Again, a new addition to our setup. The Kaos Pad 3 distributed by Korg is at it’s core a sampler with some added features. 

The Kaoss Pad 3 offers a wide range of real-time effects, including filters, delays, reverbs, modulation effects, and more. Its unique interface consists of a touchpad surface that allows users to manipulate and control the effects by sliding, tapping, or applying pressure with their fingertips. The touchpad is highly responsive and provides an intuitive way to manipulate sound in real-time during performances or studio productions.

For us it’s a way to take a break in our live coding. One of us can interact with the KP3 while the other is coding. Taking some time off during an intense performance is necessary as it allows a little moment to think about our future actions and feel a bit more in touch with our public.


Thanks for reading, as always feel free to ask any question. We’ll get more in depth about the gritty stuff soon enough !