Drum Machine pt4
Mar 3, 2026
Today is a milestone for the drum machine (affectionately named Phil). Earlier tonight it played it's first practice session with other musicians! It only needed a reboot once in a 2 hour session. I am proud of Phil.
New Hardware
As envisioned in part 3, the audio was cleaned up with a DC decoupler. A large, expertly selected LCD was integrated with the HD44780_LCD_RPI library. And, crucially, the enclosure was once again made with a shitty cardboard box. The shitty cardboard box (or SCB) stage of design is incredibly important for daydreaming types like myself.
Why is the SCB stage so important? It's an application of that old saying, "the perfect is the enemy of the good". If I were to wait around for the time and energy to create a "nice" enclosure, I'm going to lose steam on the project. "Nice" enclosures take too long to make, but a really quick solution keeps the momentum going. Software developers might call this the Minimum Viable Product, which does sound nicer than a Maximally Shitty Product, but I'm not here to fool anyone. I'm just trying to trick myself into completing projects. I suppose there is fooling afoot, but it is limited to myself.
New Software
The LCD screen is the main change. Configuring the i2c controller with wiringPi requires root access/capability magic, because it's using libbcm2835 under the hood. I didn't feel like learning new weird configurations, so I used old weird configurations instead: the compiled program gets the SetUID bit set to run it with the privileges of the file owner (root). Running the program directly as root won't allow the audio session to work, and I didn't feel like dealing with sudoers configs, so we're going with SetUID.
When working on this for hours at a time, having a bright LED shine into your eye gets old really fast. This makes wiring difficult. I tried using wiringPi to PWM control the LEDs to reduce the brightness, but I quickly found that wiringPi's software PWM control operates at audible frequencies, i.e. you could hear it over the speakers. Audible LEDs sucked more than the audible CPU load feature, so my solution was to stop using the really bright LED. Could you imagine a person like that? "Hey, your outfit isn't acceptable in the workplace, could you dial it down a notch?" "Sure, I'll just scream constantly instead." If that person sounds insufferable, wait til you meet this LED. For personal reasons, I've stopped using the LED.
Pictured: Light emitting JERK
(This problem is entirely solvable by changing the series resistor, but I'm going to wait until V2 before I open that can of worms.)
Moving on - I've added the ability to shutdown the system by holding the rightmost switch for a while. Also, there is now a clean shutdown routine rigged up with std::signal for catching the SIGTERM that systemd sends to stop a service.
Next steps
- The battery/speaker combo doesn't turn off or timeout after the raspi shuts down. V2 will feature a power management circuit. For now, I just disconnect the power cable after the system shuts down.
- I figured out how to get h2cli sending MIDI time sync and transport messages - I want to use this to blink the LEDs in sequence with the song.
- Sometimes the audio playback is crackly at startup (in an xrun/dropped audio stream kind of way). I need to dig deeper into what's causing this. It generally goes away after a minute.
- The boot time is a minute or two long. That's actually perfectly reasonable for the use case, but it offends my sensibilities, so I'll spend a large amount of time fixing it.