“Just to respond to your question a little bit; not many people – not even pro’s – would invest the time or trouble it would take to do here what you want done – it’s not worth it. Obviously it CAN be done, but it’s not sensible. The big question is who would even do the design work, as well as the physical work?”
– gearslutz forum reply
One day it occurred to me that a laptop has no place on stage. It occupies too much of my mind while playing and makes it almost impossible to talk to people while setting up and tearing down. So it seems like a total no-brainer to have an Ableton-powered pedalboard that looks and handles just like any other pedalboard. I have a professional background in software engineering and kiosk automation and I knew this idea was total doable.
So why hasn’t this been done before?!? Because it’s a total pain in the ass to research and build! But it all works perfectly and now I have an incredibly powerful pedalboard that I can throw in a gig bag, cart off to the stage, and just plug in and start playing. Plus, now that I paved road with research and toil it would actually be fairly easy to put this together yourself should you desire.
Seriously, we should all be using something like this. It’s that great.
This project was massive, and so this is not a tutorial. The top requirement is to create a black-box where the only user interface is an on-off switch. The PC is headless (no monitor/keyboard/mouse) and all computer control is via MIDI. My personal stage setup uses Push, the FBC1010, a microphone, and I use a combination of Ableton Live and Max For Live to loop and do other crazy digital things on stage.
The whole setup is optimized to work with my personal stage setup, but I think most of it is applicable to whatever stage setup you have as well. I hope it’s useful!
Challenges (in order of difficulty):
- Push Looping M4L device
- MIDI Remote Control App – PKMidiCron
- Board Power & UPS
- Headless PC Automation
- Hardware Selection
- FCB1010 DC power conversion
Notable Hardware Components:
- Intel NUC i5
- LYT 32 Pedalboard
- RME Fireface UCX
- Behringer FCB1010
- Alto Zephyr ZMX52 Mixer
- 12V, 240W Switching Power Supply
I used the very light LYT32 Pedalboard because I was afraid that all this hardware would weigh a ton. It’s fairly flexible, but altogether very acceptably rigid and easy to handle.
This whole pedalboard concept is bunk without a top-end audio interface. The interface you choose must be a slam dunk, as it is the heart of the whole setup. I shopped around for a year before finally pulling the trigger on the RME FireFace UCX. It uses USB and has the stable and near perfect (<2ms) latency required for a live instrument gig.
The audio interface will only be as stable as the USB chipset on the PC, and only the smallest modern PC will fit into the pedalboard. The Intel NUC (4”x4”) D54250WYK is small, stable, cheap, and can run on 12V. It’s a slam dunk for this project.
The Alto ZMX52 mixer was a late but important addition. It primarily gives me a volume knob when powering the board on and off allowing me to plug straight into the PA making one less thing I have to carry to a gig. It also allows another person to plug in to my PA if they want. I bought this mixer because it was the smallest one that had 1/4” jacks. DC power would have been nice though.
Most guitar pedals use very little power. But in this case the PC and audio interface draw quite a bit more power and force us to build our own solution.
The presence of the PC makes the power requirements for this project incredibly complex. Remember, the main goal is to build a pedalboard that behaves like a piece of hardware at a gig. This means that I want to plug it in and have it work without worrying about the fact that a PC is in there. When the gig is over I want to just turn it off and throw it in the truck.
There are two main problems here. First, the PC still needs to be shut down gracefully after the power is cut, or you will see the following problems. Keep in mind that user interaction via keyboard and mouse is impossible.
- Fatal/Nonfatal disk corruption.
- 30-second boot delay for safe mode prompt.
- Infinite boot stall if showing prompt without timeout.
- Ableton preventing startup until clicking OK on “crashed last time” dialog.
- Ableton disabling audio interface on next boot.
- Several other critical problems I can’t remember right now.
Bottom line, the PC needs to be shut down safely when the power is killed, and the audio interface needs to remain powered up during shutdown to avoid Live from disabling it for the next boot. The only way around this is a UPS with a shutdown controller. The OpenUPS is an excellent and extremely compact power supply that monitors the main 12V input voltage from the wall and automatically switches to use the 6 battery cells when that input voltage drops.
I configured it to send a shutdown signal to the PC’s ACPI power button when the power supply switches to batter, and then will eventually cut battery power completely after a specified timeout (to turn off the audio interface and low-voltage drain of the PC motherboard while in off state). The AutoIt script (described here) uses MS Windows events to detect when the PC switches to battery power and gracefully shuts down Ableton Live, preventing the OS from endlessly displaying the prompt saying that “the following apps are preventing the system from being shut down…”. If the shutdown procedure gets stuck on this screen then the OpenUPS will cut battery power with the PC still running.
I am powering both the PC and the RME audio interface through the OpenUPS (to prevent the RME from being disconnected before the machine shuts down, thereby confusing Live into disabling it), so keeping an eye the audio interface provides an easy way to tell when battery power is still on. This is important because you can’t turn the board back on until the UPS has completely killed battery power or it will mess up the PC startup sequence. It’s a complicated but necessary and actually very elegant solution for this problem.
The PC and RME audio interface require too much power for a conventional pedalboard power supply, so I had to build one. The challenge was to find a cheap and light weight 120AC to 12-18V DC power supply that didn’t create too much noise in the audio components. As it turns out, the cheap lighting power supplies out there have good, clean power, high amperage, and are about $30 and available everywhere on eBay.
The only problem then is soldering up the voltage regulators and filters (aka capacitors) to provide the exact voltage that my digital components need to run. I’ve done a lot of soldering in the past but this was my first circuit board so I had to learn about voltage regulators and capacitors using electronics.stackexchange.com (relevant forum posts here, and here) and gearslutz (relevant post here) in order to place my order on digikey.com. Unfortunately the local electronics supply place and local Radio Shack didn’t have the parts I needed.
Here are the components and their power requirements in order:
- 18v 500ma – Alto Mixer
- 12-19v 10A – Intel NCU
- 12v 3A – USB Hub
- 12-18v (15v) 400ma – Eden
- 9-18V (12V) 2A – RME
- 9v 300ma (120v) – FCB
- 9v 200ma – POG 2
- 5v 1A – Push
207W total? That’s kind of a lot. The mixer and EDEN pedalboard were a pain because the mixer 18V *AC*, and the digital EDEN doesn’t actually use the power requirements listed on it’s case. For these I just cheated and crammed their wall warts into the board (see photos). *sigh*.
“Headless” means the on-board PC will run with no monitor, mouse or keyboard. This means that everything has to be pre-programmed to boot and function perfectly with no user interaction. Every boot prompt, yes/no dialog, or error state (f.ex. USB audio interface disconnected/connected) must be accounted for. This piece is harder than you might think.
To accomplish this piece I used an AutoIt script to detect error messages and usb connect/disconnect, as well as to safely shutdown all apps when the PC goes down for shutdown. AutoIt is an extremely powerful automation tool with a very large community and I highly recommend it.
Simulated User Interaction
Ableton Live is a pain to automate on a headless system. It permanently disables an audio interface whenever it is disconnected or Live is killed ungracefully requiring user interaction to get it running again. Further there are a few error dialogs (“Live crashed last time”, “Do you want to load from undo history?”, ugh….) that prevent Live from loading, also requiring user interaction.
Ableton uses their own UI toolkit and doesn’t set proper window titles on their dialogs so you can’t detect standard MS Windows controls using an automation scripting tool. I ended up writing a rather complicated AutoIt script that:
- Detects when the RME audio interface is plugged in and sets the audio interface in Live’s preferences, assuming all the appropriate buttons and drop-down menu items are always in the same pixel location due to the inability to detect MS Windows controls.
- Listens for various Live dialogs preventing app startup:
- “Crashed last time” (ok button)
- “Quitting will stop audio” (ok button)
- “Save before closing” (yes / no buttons)
Here is the full AutoIt script I used. It is fairly well documented and organized so should be an easy read.
I found the RME/ASIO midi drivers to be extremely finicky with Ableton Live and other midi apps. In particular, I have loopMIDI (midi virtual loopback device used in my M4L device and Live set), Live, and PKMidiCron (a midi remote control app I wrote for this project). Live would seem to hog the RME midi driver sometimes, and I still haven’t figured out exactly how to avoid it.
So I used a windows batch script to slowly and intentionally launch each app one at a time which delays the startup time a little but seems to work OK. You can download the full startup batch script here.
I can say with confidence that any problem that arises on stage will be fixable within 30 seconds of remote desktop time. Remote desktop is the best/only way to add new patches or commands to the midi remote control, update the system, etc. So I will always bring my Macbook to the gig in case a problem arises, but am not afraid at all about not being able to play the gig because all problems that arise with the pedalboard are super easy to fix on stage.
VNC (Remote Desktop)
I occasionally have to remote into the machine to troubleshoot or reconfigure the pedalboard PC. MS Remote desktop is a no-go on a remote system because it actually logs out the current user and changes the desktop resolution, which will kill the programs we so carefully launched with the startup script. VNC runs in the background and doesn’t interfere with the current user session, and there are free clients available.
Joining and creating WiFi networks can be problematic with a headless system, and automating windows wifi adaptors via the command line is a nightmare. The Intel NUC’s built-in wifi adaptor is set to join my home wifi network if it exists, but it won’t find that network at a gig and then we’ll be out of luck if we run into a problem on stage.
So I bought an micro-sized Intel USB wifi adaptor to create it’s own network (called “pedalboard”) with it’s own static IP range. This way I can connect to this network from my macbook on stage and fix whatever problem arises. Unfortunately creating an ad-hoc network on windows is a total PITA. I downloaded a third-party app to do it (Connectify: http://www.connectify.me), but it sometimes crashes. WTF Microsoft?!?
Developing & Updating Live Sets & M4L devices
As an experienced software developer, I use a fairly strict development / production setup. I develop my Live sets, M4L devices, and PKMidiCron app on my macbook pro with large computer monitor and desk, and then push the changes to the pedalboard via FTP only when the software is totally solid. Fixing bugs only present on the NUC is expected, but it is imperative that I do not get into the habit of developing new features on the pedalboard in order to prevent it from becoming more than the simple black box that it was designed to be.
This workflow takes some precision and could potentially be very challenging for someone without that attention to detail. One must account for small differences between a PC / Mac systems (f.ex, different midi/audio device names in channel routing), but for the most part Ableton and Cycling 74 have created a very portable system and I have had very few problems once I get the ground rules figured out. I can even update a live set and re-load it without rebooting the system since Live releases all references to files on the filesystem between the loading of Set files. Great job, guys!
I created an I/O bus template in Live to accommodate for differences in audio and midi ports to simplify cross-platform support. This bus has for example a track with midi input for the Mac FireFace midi input and another for the differently named windows input port, each sending their output to another track which actually handles the input.
To develop Live & M4L on my macbook pro, I just unplug Push and the RME FireFace from the USB ports of the Intel NUC and plug them into my macbook when in my studio. Then I push the changes to the pedalboard, and plug them back into the NUC’s USB ports.
This is the fun one. I have a several live sets that I use on stage, and I needed a way to change between them without using a keyboard and mouse. Sadly, I couldn’t find ANY software out there that could open a file or run a program when a particular midi message is received. So, I decided to write my own.
The app is called PKMidiCron and will soon be in the mac app store. It runs on both Windows and Mac but I currently only have plans to release it through the Mac App Store. I’ll think about releasing it for Windows after that. This was a significant Python/C++ project all on it’s own, but it’s development falls outside the scope of this article.
PKMidiCron allows you to manage a list of actions for a particular midi message. For example, in the pedalboard it listens to CC #124 on channel 16 to change the current Live set. CC 124, Value 1 loads one set file, CC 124, Value 2 loads another set file, and so on. This allows my to play a song and totally whack out all the knobs and levels, and the reset them all by just reloading the set file. The AutoIt script automatically detects and clicks the “yes” button on the “Do you want to save your changes” dialog.
The FCB1010 is a clear choice for this pedalboard. The unit ships using AC wall current to run so I had to convert it to 9VDC using this excellent tutorial: http://voes.be/fcb1010/pdf/fcb1010%20phantom%20power%20adaptor.pdf. I was very careful here since I didn’t want to have to buy another FCB if I fried this one!
The result is that it will run on BOTH wall AC current (120V in my case) OR 9VDC. The bridge rectifier setup make sit impossible to blow the circuit, since you can have both the wall power and the DC power plugged in at the same time and it will automatically choose the most appropriate power source. Totally awesome.
Push / M4L Looping Device
I wanted a versatile live looping setup that would allow me to really improvise on stage. The idea was to have several loopers for each of violin, bass, vocals and electric piano, and to be able to record the loops and then tweak and re-record as I go. Each looper track has its own effect preset, and you can even queue up recording on one looper while another looper is playing. While Andrew Bird is a far better musician than I am, he’s got nothing on this looping setup!
To do this I programmed a Max For Live device to find all the Ableton Looper devices in the Live set, and put their track levels (levels look very cool!) on Push’s button grid when in session view. Then the usual arm/mute, sends, and device macros are all available in the usual way on Push. I start and stop each looper using pedals on the FCB1010 or buttons the custom Push grid interface which also includes dub/record, stop, clear, reverse, and track indicators. Tracks are auto-armed when recording starts, but not dubbing or stopping.
This M4L device and its accompanying Live set are now two years in the making, and are used in 90% of my songs. I will put together a comprehensive blog post with a demo video on it later!