diy-synths: a list of open hardware synths you can build yourself

A catalogue of buildable instruments, firmware included

The README describes the project in two sentences. It is a list of synthesizers and related hardware you can build on your own, and all designs are open-source including firmware.

The firmware clause is the one that matters. A schematic with no source is a drawing, and a drawing of a synth is a weekend of frustration. A design where the firmware is published is a project with a known end state, because someone has already written the code that makes the board make a sound.

The project is published in two places, a web version at diy-synths.snnkv.com and the README itself, and the README points to a third place for participation, a SUBMIT DESIGN link and a DISCUSSION link that both go to the repository's GitHub Discussions. The README asks you to submit designs that are not in the list and to discuss your building experience there.

The repository metadata describes it as a list of open-source synths, with topics that include awesome-list, diy, hardware, sound and synthesizer. That is an accurate self-description: this is a curated list in the tradition of the great awesome lists, with the difference that the entries are physical objects you solder rather than libraries you install.

From a Teensy drum machine to a DX7 clone

The range of entries is what makes the list worth reading rather than scanning.

Several entries are clones of commercial instruments. Aciduino is a Roland TB-303 step sequencer clone aimed at live interaction, Nava is a clone of the Roland TR-909 drum machine, Mini Dexed is an FM synthesizer closely modeled on the famous DX7, and NESizer2 is a NES 2A03 chip controlled by an ATmega328 with battery backed patch memory. Mega MIDI is a MIDI-compatible Sega Genesis synthesizer using real sound chips, and Mozard is an Arduino synth based on the Mozzi library.

Others are platforms rather than instruments, designed to be built on repeatedly. Bread Modular is an affordable, compact modular synth platform, MIDIbox is a MIDI hardware platform, OpenDeck is a platform for building MIDI control decks, the Norns shield is a dynamic instrument, creation platform and musical computer, and the Kastle instruments are described as patchable, pocketable and open.

Then there are the hackable descendants of commercial hardware. Meeblip Micro, Meeblip SE and Meeblip Triode are all described as hackable monophonic synths, with the Triode based on an ATmega32, and Echo Rockit is a compact synth and effect processor. Faderbank 16n is a 16 fader MIDI controller compatible with the modular world, and Le Strum is a compact and simple MIDI strummer.

The odd entries are what keep the list interesting: the Hidden Sound Explorer is an electromagnetic fields analog transducer, the Noise Toaster is a simple full analog noise synth, and Grandbot is a generative, pattern-based MIDI arpeggiator.

The README is generated from a data file

The repository layout shows that the list is produced by tooling rather than maintained by hand in Markdown. There is a `_data` directory, a `db.json` file, a `jlist.js` file and a `gen-readme.py` script, next to the Jekyll machinery: `_config.yml`, `_includes`, `_layouts`, `_posts`, `_drafts`, a `Gemfile` with a lock file, an `index.html`, a `feed.xml`, a `sitemap.xml` and a `styles.css`.

The likely flow is visible in the file names even though the README does not describe it. The entries live as data, the script generates the README from that data, and the Jekyll site renders the same data for the web version. The `_posts` and `_drafts` directories are how a Jekyll site handles dated entries, which suggests some of the list content is written as site posts rather than as plain records.

The supporting files fill in the rest of the site. There is a `CNAME` for the custom domain, a `404.md` page, `about.md` and `dev.md` pages, a `watchlist.md` for designs that are being watched rather than built, `gisqus.json` for comments, `pics/` for images, and a `.devcontainer` directory so the site can be worked on in a container.

Two of the file names deserve a note because they say something about the scope. A `watchlist.md` implies the list distinguishes between designs that are confirmed and designs that are being tracked, and a `db.json` implies there is a schema behind the entries rather than a free-form list of links.

The primary language recorded for the repository is JavaScript, and the scripts that keep the list and the site in step are `jlist.js` and `gen-readme.py`.

The site is built in Docker with Ruby and Jekyll

The Dockerfile at the root is the build environment for the site, and it is a Jekyll build environment in Ubuntu 24.04 with a pinned Ruby:

FROM ubuntu:24.04

ENV RUBY_VERSION=3.3.3

The apt layer installs the prerequisites for Ruby and for GitHub Pages, which the comment above it names explicitly, and the list is long and specific: git, curl, autoconf, bison, build-essential, libssl-dev, libyaml-dev, libreadline6-dev, zlib1g-dev, libncurses5-dev, libffi-dev, libgdbm6, libgdbm-dev, libdb-dev, apt-utils, nano, html-xml-utils, locales, python3 and python3-pip.

Ruby itself is installed through rbenv, with the version builder cloned and run, and the version installed and set globally:

RUN rbenv install ${RUBY_VERSION} \
  && rbenv global ${RUBY_VERSION}

The container therefore reproduces the toolchain exactly, which is what you want for a site whose content is generated and whose output has to stay byte-identical between the local build and the deployed one. The locales section also sets the container to C.UTF-8 and then to en_US.UTF-8, with the language environment variables following, so the rendered output does not depend on the machine that built it.

The `.devcontainer` directory at the root serves the same purpose for contributors who would rather not run the Docker image directly.

Submissions and discussion happen in the same place

Both links in the README's header point to the same destination, the repository's GitHub Discussions, one labelled SUBMIT DESIGN and one labelled DISCUSSION. The README text explains the split in a sentence: submit designs which are not in the list, and discuss your building experience.

That is a small design choice with a large effect on how a list like this stays true. A list of buildable hardware goes stale in a specific way, which is that a design stops being buildable, or the repository moves, or the firmware stops compiling against a newer toolchain, and nobody notices because the link still resolves to a page. Sending both new designs and build reports to the same discussion area puts the evidence next to the claims.

The `watchlist.md` file fits the same pattern. Designs that are not yet confirmed can be tracked separately from the main list, which is a way of handling the same honesty problem without deleting entries that people still care about.

What the README does not describe is any review process beyond those threads, no checklist, no test builds, no verification that a listed firmware compiles. The list's authority therefore comes from the community around it rather than from a stated standard, and that is worth knowing before you order a board based on an entry.

A list without a licence, releases, or a release process

The maintenance picture is straightforward. The repository is not archived and the last push was on 2026-10-11, and the recent releases are empty, because there are no GitHub releases. That is the correct arrangement for a list, since a list has no versions, only entries.

The licence is the open question. The repository listing records the licence as one that GitHub cannot classify, and there is no licence file among the top-level entries, which are the.devcontainer,.githooks and.github directories, the Jekyll site files, the 404, about, dev and watchlist pages, the CNAME, the Dockerfile, the Gemfile, the data and script files, the images directory and the README. So there is no stated grant for the list content itself, which is a different question from the licences of the individual projects it links to, each of which carries its own.

That distinction matters for anyone who wants to reuse the list. The entries point at other people's hardware designs with their own licences, some of which are open hardware licences and some of which are not, and the list itself does not grant anything about the text or the data behind it.

The project is presented as a community project, and the web version and the discussions are the places it is maintained from. For a reader, the practical advice is simple: use the list to find a design, then go and read that project's own documentation, licence and issue tracker, because that is where the build instructions and the caveats will be.

Editorial conclusion

diy-synths fits a builder looking for a project to solder, or someone who wants to study how an instrument is put together, and it is the fastest way to find a design with published firmware rather than a schematic and a forum thread. It is the wrong tool if you need a supported product, a bill of materials, or a guarantee that the entry still builds, since the repository states no review process beyond its discussion threads. Verify first that the specific design you picked still has a reachable repository and current firmware, and read the licence of the individual project rather than assuming the list carries one.

Frequently asked questions

Official sources

1. Atarity/diy-synths on GitHub
2. Issues
3. Project website
4. README