DSLemur
Repurposing a Nintendo DS as a wireless touch controller for music and live visuals performance.
The Nintendo DS hardware: two screens, stylus-based touch input, physical shoulder buttons, and homebrew Wi-Fi support — the constraints that shaped the entire design.
DSLemur was an interaction design experiment exploring how a Nintendo DS could be repurposed as a wireless controller for music and live visuals performance.
The idea came from seeing expensive multitouch hardware controllers used for performance and wondering whether a cheap handheld gaming device could support a similar kind of control. The Nintendo DS had two screens, a stylus-based touch interface, physical shoulder buttons, and homebrew development libraries that made Wi-Fi communication possible. That combination made it an interesting candidate for a portable performance controller.
The project was less about creating a finished app and more about testing whether the hardware, screen size, touch targets, and development environment could support a useful control interface.
A range of interface layouts built in Lemur: Multiballs, Multisliders, and Sliders, each sending MIDI to be used for different video performance controls or synthesis parameters.
I was the sole designer and technologist on the project.
- Researching Nintendo DS homebrew development
- Setting up the development environment
- Learning how to compile and install test apps on DS hardware
- Researching hardware specifications, graphics limits, sprites, and screen resolution
- Designing interface layouts for the DS screen size
- Testing touch target size and stylus interaction on the actual device
- Exploring screen switching behavior using the physical shoulder buttons
- Designing controller screens for live visuals and performance use
The challenge was designing within the constraints of commodity gaming hardware.
The DS had a low-resolution screen, limited graphics capabilities, a sprite-based visual system, and only one touch-sensitive display. The top screen could show information, but only the bottom screen accepted stylus input. The interface also needed to work in dark music venues, where quick recognition and large touch targets mattered more than visual detail.
Another challenge was technical setup. Getting a homebrew development environment working, compiling a test app, and installing it on real hardware took significant research and experimentation.
I started by researching the DS hardware, homebrew development libraries, graphics capabilities, sprite limits, and Wi-Fi communication options. The goal was to understand what could realistically be built before designing an interface that the device could not support.
I created interface layouts in Photoshop at the exact DS screen size. This helped me understand how many controls could fit comfortably and how large touch targets needed to be. Because the controller would potentially be used during live performance, I designed for low-light readability and fast interaction. Controls needed to be large enough to use with a stylus without careful aiming.
A key part of the project was getting the concept app installed on a real Nintendo DS. Testing on the actual device made it clear whether sliders, buttons, and other controls felt usable at that size. It also helped reveal which ideas were too ambitious for the graphics system. Multi-slider and multi-ball concepts were appealing, but they likely would have required more custom C programming rather than image-based sprite layout.
Because only the lower screen had touch input, I explored using the shoulder buttons to manage screen switching. One shoulder button could switch between the current controller screen and a menu, while the other could cycle forward through available screens. This left the touchscreen focused on performance controls while still allowing access to different modes.
Faders, Pads, and Information control screens offered different ways to trigger and shape sounds, each layout tested for ergonomics using the stylus on the DS touchscreen.
Color coding became a key design language, differentiating tracks, voices, and functions at a glance without relying on text labels too small to read during a live set.
The interface was shaped by the DS screen size, sprite system, stylus input, and split-screen hardware. Constraints were the starting point, not an afterthought.
For live performance, controls had to be large enough to use quickly and confidently without precise aiming.
The visual design needed to remain readable in dark music venues. High contrast and minimal visual noise were more important than decoration.
The concept was designed as a smaller, portable companion to larger performance controllers rather than a full replacement.
Running the app on actual hardware was essential. The interaction could not be judged accurately from desktop mockups alone.
DSLemur became a Nintendo DS homebrew app design and proof of concept for using a handheld gaming device as a wireless controller for visuals and performance software.
The project showed that the concept was possible in principle, but also that further development would likely require a developer partner with deeper C and Nintendo DS graphics experience. The work clarified what parts of the interface were viable, where the hardware limits became significant, and how the DS could support portable touch-based control.
The project reinforced the importance of testing interaction designs on the real device, especially when working with unusual hardware. Touch target size, screen resolution, stylus feel, and low-light readability all became clearer once the prototype was running on the DS.
It also showed how much setup work can affect experimental hardware projects. If I continued the work, I would document the full development setup, preserve the working environment, and keep a dedicated machine or disk image so the toolchain could be restored reliably.