Portable 3D-Printed DAW, Synth and Sampler Build

Oct 29, 2026 Last reply: 12 hours ago 3 Replies
Jump to replies (3)

The maker calls user interface design the hardest part of this project, and that shows in how much care went into it. The whole application is written in C++ with the Juce framework, which needs an operating system underneath it, so a Raspberry Pi sits at the heart of the device. Juce has no graphical layout tool, so every screen is laid out in code, which the maker prefers since it suits version control. In my view that is a disciplined way to work, even if it sounds slow.



The hardware itself is a grey 3D-printed casing with exposed screws holding a rectangular faceplate around its perimeter. On the upper left there is a 4x4 grid of mechanical function keys, with an analog thumbstick module in the lower left corner. Seven rotary encoders carry color-coded caps, and a two-octave keyboard of 3D-printed piano-style keys runs across the bottom. The keys are actually mechanical keyboard switches, and the maker found the mechanical keyboard community's design tools made working with them easier. I think repurposing keyboard switches as musical keys is a genuinely clever move for a DIY build.



On the software side, it covers a lot: a multi-track arrangement view, an eight-channel mixer with volume meters, a zoomed-in piano roll, and a built-in four-oscillator synth called 4OSC. The walkthrough includes tapping in a tempo, loading a drum sampler that sequences a sixteen-step pattern, trimming a bass sample via encoder-based beat navigation, and inserting chorus, delay and reverb. Pitch bend is done through the joystick while tweaking saw levels, filter cutoff and ADSR.



One open point: the scrolling animation did not come out as smooth as the maker wanted, and they think switching from the software renderer to open GL might help. Nothing has been open sourced yet either; the maker may release it after polishing the CAD files.



Project by GrievousAngel93. Watch it on their YouTube channel:

formatting link


Laying out every screen in code rather than dragging boxes in a graphical editor seems like a smart call to me. It pairs nicely with the maker's preference for version control, since code diffs track changes in a way a saved layout file never quite does. The trade-off is that iterating on visual polish becomes slower, which might partly explain why the scrolling smoothness is still being chased.

Curious about the display situation. One overhead image shows what looks like a monochrome panel with a grid timeline and a timecode readout, but the color LCD is also mentioned. Did the maker swap screens between iterations, or is the monochrome look just a theme? Either way the layouts look clean and very approachable for a DIY interface.

If the maker ever revisits the key switches, adding LEDs would be a natural upgrade. Many mechanical switches, Cherry ones included, have a space for an LED right in the housing, and there is a Sparkfun breakout guide that covers wiring them up. Lit keys would make mode switching obvious during live use and could echo the color-coded encoder caps for a more unified look.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required