Scott Manley Flies Kerbal Spaceships to the Mun With a DJ Mixer

Scott Manley teaches orbital mechanics through Kerbal Space Program, and he also DJs. For his latest project, he wired those two lives together on a whim, writing a small Python program that reads MIDI events from a portable mixer and turns them into spacecraft commands. The question he set out to answer was simple enough to print in all caps: can you fly a spaceship using a DJ mixer? After one messy airplane test and one surprisingly clean lunar landing, the answer was yes.

A Numark DJ2Go2 is at the core of this operation, but in a very small way, as this 2-channel USB controller is small enough to carry in a backpack. Oh, and it runs totally on MIDI, so no power issues there. Manley needed to complete a task, so he began mapping inputs that were never intended for pitch or yaw to do so, among other things. He did it all through a config file, which allowed him to adjust the dead zones and response curves without having to start over. As a result, Kerbal’s kRPC remote control interface could accept the translated commands and send them to the 2015 simulator. Throttle originated from a slider on the speed dial that, if yanked the wrong direction, does the opposite of what you’d expect. The attitude was taken care of by the little self-centering sticks and the jog wheels, which always seem like you’re playing with a vinyl record when you only need a few degrees of pitch, such as when you’re descending. Finally, buttons were utilized to control staging, SAS modes, RCS, landing gear, and action groups.

First up was a plane, and it was a close call because the plane almost won, but Manley quickly discovered that the rotation on the mixer was far too delicate when close to the ground. He nearly crashed the plane into the trees by over-correcting, then spent far too much time battling the camera before eventually figuring it out. At that point, he stopped treating the board as a flight stick and began treating it as a collection of poorly labeled sliders. He described the learning curve as steep and the configuration as unsuitable for low-altitude flight. SAS modes that propel a rocket into space are ineffective when flying a winged plane that follows the terrain. That particular flight landed on the runway due to sheer chance and early saves, rather than design.

When it came to rockets, it was a very different situation. Manley fired one, kept a steady path with the jog wheels, and then let the SAS handle the ride through the first stage burn. It wasn’t until he was climbing that things became a little unstable, and he had to cut the thrust to save the thing from frying itself, before staging, restarting, and sending it on its way. After a few minutes, they were in a 100-kilometer circular orbit, with no drama. From there, he focused on the Mun, decreased the orbit’s lowest point, and began a drop toward a good, smooth crater that would be far superior than the surrounding ridges for landings. Then it was simply a matter of directing it down to the ground with the jog wheels until the lander tipped in and landed on the soil.

Time acceleration was a continual battle for him because a poorly mapped reset caused the clock to spool back and added some annoying visual artifacts, so he saved frequently and flew the coast phases in real time more than he wanted to. Don’t even get started on the radar altitude, which never seemed to appear on the board, thus the last hover was a bit of a gamble, relying on camera zooms and enough practice to overcome the homing inaccuracy. The familiar layout of staging buttons and SAS modes, however, came readily to him, as it was similar to thinking about mixing tracks as a DJ, with distinct cues and a continuous fader. The problem was that planes required a continual stream of micro corrections right near the ground, and rockets provided him with extended burn periods and some nice staging events, but he needed a computer that could at least retain its position while he mixed it all together.
[Source]