The firmware mod explosion has me excited and skeptical

I finally ordered an M-VAVE FM-1. Fifty dollars plus shipping from Walmart. After looking at it for months, watching the firmware scene around it take off, and wondering what it might do alongside COMPA, I figured: what the hell. Time to get my feet wet.

I love seeing people turn inexpensive instruments into things their manufacturers never imagined. I also want to know what happens after the excitement wears off and somebody just wants to make music.

Over the past few weeks, the FM-1 has become a remarkably busy playground for custom firmware. Now Behringer is showing KICK, an MPC-style workstation with published source code and a reported $150 target price. Akai has followed with SampleKey teasers and promises to open both that instrument and the existing MPC Sample to community development. Those announcements landed close enough together to make the whole thing feel like a sudden change in direction. Behringer’s repository, KICK price reporting, Akai announcement coverage

As someone building music software, I find that exciting. As someone buying instruments, I have questions.

The FM-1 makes sense to me partly because of what I paid for it. At $50, I can approach it as an instrument, an experiment, or a little development platform without expecting it to replace my studio. I haven't received mine yet, so this is enthusiasm about the possibilities, not a hands-on review.

I already use a Roland T-8 and P-6, and recently ordered an S-1 instead of buying the FM-1 I had sitting in my cart. The footprint appealed to me before the firmware wave did. FM synthesis itself hasn't been my main attraction; it just isn't usually the sound I reach for. Now the prospect of exploring different engines and workflows makes the little box much harder to ignore.

The M-VAVE FM-1, before any firmware experiments. Product image: M-VAVE.

Its limitations are part of the story. Community hardware work identifies a JieLi AC791N platform, with roughly 512 KB of RAM and 1 MB of flash. We're talking about a fraction of a megabyte of working memory. Developers are squeezing instruments into constraints that look almost absurd beside today's computers. That makes the results impressive, but it also means every feature competes for a small budget of resources. FM-1 hardware findings, FM-1 memory limits

Projects such as Felucca, SLOOP and Melodee, along with browser installers and firmware directories, have made the FM-1 much more than one inexpensive FM synth. Some projects develop their own direction; others build on an existing firmware. The appeal is already broader than downloading another set of sounds. FM-1 community directory

M-VAVE has joined in with its own FM1 Open project. Its application code uses GPLv3 with an SDK linking exception, while the device engine is supplied as a binary SDK under separate terms. That is meaningful access for developers, with boundaries worth understanding. Even within this one scene, “open” covers different arrangements. M-VAVE’s source and license description

For some people, the fun will be writing their own firmware. Others will find a community release that fits, or discover that the stock software already does what they need. Watching people dedicate different colored FM-1s to different firmware is funny and kind of wonderful. I can see the appeal of a shelf full of cheap little instruments, each doing its own thing.

There is also paid firmware. Groove OS currently costs $29 as a one-time purchase. My immediate reaction is to compare that with the $50 I paid for the hardware. That's a substantial extra purchase in this particular context. But being a mod doesn't erase the work involved. If the workflow, documentation and support make it worth paying for, that's a reasonable decision for a musician to make. Groove OS pricing

I build commercial software myself, so I understand the time involved in making something people can rely on. What I care about is whether the result earns its place in a setup.

Custom firmware also brings practical costs. You need to know how to preserve your projects, switch back, and recover if something goes wrong. A convenient browser installer helps, but project formats don't automatically travel between different firmware. M-VAVE's own documentation makes that distinction. The purchase price may be small; the music saved inside can still matter. FM1 Open backup and compatibility guidance

Behringer's KICK raises a different set of expectations.

The published design looks extremely familiar to anyone who has used an MPC One. Music Tribe's repository describes a touchscreen, 16 RGB pads, a sampler, sequencer and looper, assignable controls, MIDI, USB and CV/gate connections. It includes application, audio-engine and hardware-communication code under AGPL-3.0-or-later, alongside a Buildroot Linux system. There is actual code to inspect here. KICK source and proposed features

Behringer's KICK prototype, as shown in Music Tribe's official repository. Image: Music Tribe / Behringer.

Put that next to the reported $150 target and, yes, I understand the excitement. I also want to see the finished machine.

I spent enough time sourcing Raspberry Pi hardware for COMPA to know how quickly a cheap computer becomes a more expensive instrument. My 8 GB Raspberry Pi 5 cost $150, plus tax and shipping, for a pre-owned board alone. No power supply, no enclosure, nothing to house it in. I found one seller offering it at that price, cheaper than anywhere else I could find at the time. The listings I'm seeing now are closer to $160–$165 used and around $180 new.

Eight gigabytes may be overkill for the simpler jobs some of these devices are doing. But for the kind of next-level groovebox I wanted to build, memory headroom matters. Working within the FM-1's constraints is a fascinating challenge; I also want room for more ambitious instruments, effects and workflows.

I initially bought a 7-inch touchscreen for about $50, normally around $60, in the same general class of compact touchscreen I associate with an MPC. That already put the board and display at about $200. I later switched to a 15-inch, 1080p touchscreen for a very good $75 deal because I wanted more room to work. With that screen replacing the smaller one, the costs looked like this:

That is before tax, shipping, a power supply, an enclosure, or any pads or MIDI controller. I could have chosen a lower-memory Pi or stayed with my original $35, 1 GB Raspberry Pi 3B. Those choices change the budget, but fitting a computer, touchscreen, storage and musical controls into a $150 product still makes me stop and think. My retail build costs aren't Behringer's manufacturing costs at volume; they're why I want to see what the finished KICK actually delivers.

A low target price doesn't prove that a company is selling at a loss, and it doesn't prove that the hardware will be bad. It does make me want answers about the complete package: installed RAM, storage, pad response, screen quality, audio performance and support.

The RK3588 being discussed for the final hardware deserves a fair assessment, too. It has four Cortex-A76 cores and four Cortex-A55 cores. That gives the platform substantial computing potential. If that is what ships, the processor itself could be a real strength. The KICK configuration and the software running on it will determine how useful that strength becomes. Reported processor update, Rockchip’s RK3588 datasheet

My experience with the Akai Force is a good reminder that a spec sheet only gets you so far. While developing RD303 and experimenting with other software on it, I kept noticing how clunky touchscreen interaction felt compared with the iPad. I feel that in stock workflows as well as my own experiments. I can't blame the panel alone; interface design and software responsiveness are part of that experience.

COMPA began on a Raspberry Pi 3B. Moving to a Pi 5 solved some problems, but moving to iOS changed the experience much more substantially. The touch interaction felt better. Audio Units already gave me an established way to bring other instruments and effects into the environment. I could build around a platform that already did a lot of the work I needed.

These days, I often prefer making music on the iPad to working on my Mac Studio, despite the substantial collection of software I've bought for the Mac. That's a personal preference, but it's a preference earned through using and building on these systems.

A new box needs to give me a compelling reason to move back.

Which brings me to Akai's SampleKey.

The teaser shows a compact keyboard sampler in the same general family as the MPC Sample, with keys replacing the pad grid. My first reaction was predictable: where are the pads? That's the physical relationship I associate with an MPC. A keyboard sampler can be useful in its own right, though, and SampleKey's final specifications, price and availability have yet to be announced. SampleKey teaser coverage

The video with several units lined up is the interesting one. Akai demonstrates custom virtual analog, FM and wavetable instruments, and includes MPC Sample units in the experiment. The company has said it will open the existing Sample to community development as well. That answers one question I had: this isn't only being pitched around a new keyboard purchase. Akai’s demonstration, announcement reporting

SampleKey in Akai's firmware demonstration. Image: Akai Professional / Instagram, via MusicRadar.

Watch Akai's MPC Sample and SampleKey firmware demo on Instagram

I still want to see the code, the license, the development tools and the recovery process before treating Akai's announcement as equivalent to a released open-source platform. A demonstration tells us something can run. It tells us much less about the experience of building, sharing and maintaining it.

My hesitation also comes from owning an MPC Sample.

I returned mine after running into problems using external tempo synchronization alongside Flex Beat. I made a video criticizing that experience, and it became my most popular TikTok. I wanted the device to work in the setup I bought it for.

Akai's own 1.3 release notes document Flex Beat audio glitches when changing tempo and recommend setting the effect to 100 percent dry. Turning the effect fully dry is a compromise that undermines the workflow I wanted: using Flex Beat while following another device's tempo. Akai’s MPC Sample 1.3 release notes

So an exciting synth demo doesn't settle my concern about support. The $399 MPC Sample has 2 GB of RAM and 8 GB of internal storage, considerably more room than an FM-1. At that price, I expect the manufacturer's own workflow to justify the purchase before I start shopping through community alternatives. MPC Sample specifications, launch pricing

The timing of these announcements can feel defensive. Behringer shows an inexpensive, programmable MPC-shaped machine, and Akai quickly shows its own route into the modding scene. Part of me wonders whether we're watching the old closed-box approach enter its death throes.

That's my reaction, not proof of either company's motives or financial condition. They may be responding sensibly to what musicians are already doing. The outcome I worry about is a company turning community enthusiasm into an excuse to reduce its own responsibility for finishing and supporting an instrument.

I want the manufacturer to deliver a useful product and remain accountable for it. Then the community can take it somewhere unexpected.

This distinction matters outside the big manufacturers, too. DOOM OS for the SP-404MKII is an interesting example of how much community work can add to existing hardware. Its licensing history also deserves precise language: the September 29 repository version carried an MIT license, while the October 6 version introduced a license that allows use but restricts modification and redistribution without permission. September license, October license

Calling something free to use doesn't tell me whether I can build on it. That's a practical question for anyone thinking about integrations, forks or long-term maintenance. It deserves a clear answer before a developer commits to a platform.

None of this started from nothing in October. The Deluge already has an established community firmware project built from Synthstrom Audible's released source. What feels different about this wave is the speed, the low cost of entry around the FM-1, and how prominently manufacturers are now selling the idea of users writing their own software. Deluge community firmware

AI coding tools make that possibility accessible to more people. They also leave plenty of work after the first successful demo: testing timing, preserving projects, finding crashes, documenting behavior and answering users. Those are the things that turn an experiment into an instrument somebody trusts.

Felucca's maintainer has already posted a notice about stepping back from active development to focus on new instruments and music, with occasional maintenance but no guarantee of new features or responses. I respect that. It also illustrates why a growing feature list and lasting support are different things. Felucca maintenance notice

I've felt the pull myself. You start building something to help you make music, then look up and realize you've spent your available music time developing it. Some people will discover that making instruments is what they want to do. Others will eventually want a dependable tool they can turn on and play.

If manufacturers really want us to invest years in these programmable hardware platforms, I'd like the hardware to be more adaptable as well. Give us replaceable storage, serviceable controls, documented connections and a credible route to upgrading the computing side. My ideal is closer to a computer I can maintain and improve over time.

Socketed RAM and a drop-in processor won't be practical in every inexpensive embedded design. Replaceable compute modules or supported board upgrades could still move things in the right direction. If the shell is supposed to outlive the software it ships with, help it outlive its original computing limits, too.

That experience is part of why COMPA ended up where it is. Its original purpose was to help people get more from the grooveboxes they already own. My open-source work on Pi Link Audio, Force Link Audio and COMPA for Raspberry Pi sits alongside the commercial iOS app. I value both approaches, and I believe continued development and support are worth paying for.

I'm also working on COMPA Relay Mod for the SP-404MKII. The aim is focused: improve particular communication and control workflows with COMPA, keeping the scope tied to what helps the two work together. I'll share more as that work is ready.

For the FM-1, the next step is much simpler. Receive it. Use it. Find out how it feels beside the Rolands, what I actually enjoy playing, and where COMPA can help. At minimum, I plan to develop a device profile after testing it.

If you're making an FM-1 mod and see an opportunity for deeper integration, I'm open to hearing about it. Submit a COMPA Sniff Test and send the details to support@getquota.app. Tell me which firmware you're using and what you want the musical interaction to do.

I ordered the little $50 synth because I want to explore this wave myself. What will keep it on my desk is finding something I want to make music with.