In January 2005, Apple sold the iPod shuffle partly by advertising what it lacked. There was no display and no miniature library browser; Steve Jobs explicitly contrasted other flash players' tiny screens and complicated controls with a Shuffle that could simply serve up combinations from the music loaded onto it.5
Twenty-one years later, the open-source DIYPOD Shuffle borrows the name, the idea of a small local player and a random playback mode. Then it does something wonderfully predictable for a maker project: it starts adding things.1
The repository snapshot audited by IRZ contains a 128 × 64 OLED, track browsing, volume control, EQ presets, persistent settings, a battery indicator, button locking, an optional WS2812B visualizer and three games: Snake, Brick Breaker and Ping Pong.24
That makes the project more interesting, rather than less, because it becomes a small experiment in how difficult a deliberate constraint is to preserve once the microcontroller has capacity to spare.
Apple's minimum
The first Shuffle shipped with 512 MB or 1 GB of storage, no display and a switch for sequential or random playback. Apple's current identification guide still describes the 2005 model as an iPod with no display, using LEDs on its front and back for the little status information it needed.6
The missing screen was part of the pitch from day one. Apple's launch release described iTunes AutoFill selecting enough music to fill the device automatically, after which the player could present those songs in random order.5 Selection had been moved partly off the object and into the computer before listening began.
You lost the ability to walk through a library on the player, but the player gained a useful exemption: it never had to explain an on-device music library to you.
A DIY minimum
The 2026 DIYPOD begins with approachable modules: an ESP32-C3 SuperMini, DFPlayer Mini audio board, SSD1306 OLED, three tactile buttons, TP4057 charger, one-cell LiPo, 3.5 mm jack and a FAT32 microSD card of up to 32 GB.4
Music stays local, although the DFPlayer adds a wonderfully old-fashioned constraint of its own. Files are named 0001.mp3, 0002.mp3 and so on, while actual playback order follows the FAT table rather than filenames alone; the README recommends copying files in order to a freshly formatted card.4
At this point the design could remain severe. Three buttons are enough to ask the DFPlayer for another track, pause playback and expose a few status cues, but the OLED is already present, and 128 × 64 addressable pixels create a door that the original Shuffle deliberately kept shut.
Then a menu
DIYPOD's main menu contains Now Playing, Browse Tracks, Volume, Equalizer, Games, Settings and About. The same three buttons change meaning across screens, long presses expose other actions, and combinations can lock the controls or reset and rescan the audio module.2
The project has therefore reacquired the interface problem that a screenless device avoids. Firmware has to explain location, current button meanings, navigation, active options and a route back out of each branch.
That extra surface is fun to build and perfectly sensible in an educational project, yet the object has changed category along the way: “Shuffle” now behaves more like a tiny embedded platform than a player that refuses to ask questions.
To be sure, source-line counts cannot prove that games are twenty times harder than music playback; they simply show how much of the visible repository now concerns activity surrounding the music rather than decoding and advancing tracks.
Which shuffle?
The name also makes the random behaviour worth opening. In player.h, the rule is compact: choose an integer between 1 and the number of tracks, and draw again if that integer is the track currently playing.3
The algorithm remembers one thing, so an immediate repeat is impossible, while a track heard two or three positions earlier is free to return. There is no shuffled deck or permutation that waits for the whole library before reusing a song.
For a 100-track library, our calculation from that rule gives roughly a 31% chance that the first 10 plays already contain a repeated title, counting the starting track; over 20 plays, the probability rises to about 84%. The calculation assumes every allowed random draw is uniform and measures only whether a title has returned, not whether the resulting sequence feels musically repetitive.
Nothing about that behaviour is inherently wrong. “Give me something different next” is a reasonable contract for shuffle; another player can use the same label while enforcing a no-repeat deck.
Feature gravity
The repository remains tiny by modern-product standards, MIT licensed and made from components whose roles are easy to inspect.2 A builder can change the firmware without obtaining a vendor SDK, a cloud account or permission from a distribution platform; that freedom is a genuine strength of the project.
The same freedom makes feature growth cheap. Snake requires no product meeting or app-store review; somebody writes snake.h, flashes the ESP32 and the music player has become a games machine as well. Open hardware and firmware make subtraction possible, but they make addition deliciously easy too.
That is where DIYPOD becomes more useful than a straightforward nostalgia build. A limited object is shaped not only by tasks its hardware cannot perform; once capable general-purpose hardware becomes cheap, limitation increasingly requires the designer to decline perfectly feasible features.
The 2005 Shuffle benefited from industrial constraints that made ruthless simplicity useful. DIYPOD can turn a handful of inexpensive modules into a player, browser, console and visualizer, which leaves its maker with a harder engineering decision than adding the next menu item.
At some point, somebody has to choose to stop.