Firmware - Continuous Deployment

Am I the only one thinking continuous deployment should be expected on firmware releases today?

There are so many feature requests and possible also some bugs that needs to be fixed, and it takes ages between every firmware release. Why not make the firmware opensource or at least practice continuous deployment?

It should be possible to do more frequent release with small improvements.

Just my thoughts :slight_smile:

Hmm…quantity over quality?

I’m all for devs taking their time. :slight_smile:


So we can have B clones for a fraction of the price… Great idea ! #mutable


It’s not something I miss.

For some products it definitely makes sense. But for something that is more or less hardware-based, I don’t think frequent releases is - or rather should - be needed.



I’d appreciate it if more companys would consider making firmware code open source on discontinued products (likely won’t happen), but for current product lines, no. I’d rather have more companys take their time to ensure a good and stable product hits the market, than several half-assed attempts by hobbyists to improve code which get abandoned sooner then later.

Also not every feature request makes sense, there’s usually tons of them, yes, but you gotta maintain balance between what you can squeeze in gear and what would make sense having in there and provide a good UI and UX.


Aren’t we missing something here ? Continuous deployment assumes there’s an automated test suite of regression tests. I’m not familiar with hardware/firmware development, but it wouldn’t surprise me at all to find that some regression testing can only be done manually … leading to slower deployment cycles.


I’m pretty sure you can still have continuous integration on firmware build using unit tests

Also I’d actually say we need the opposite, good, stable products on release and longer product life cycles in general.

But obviously it’s a jungle out there, new products hitting the market in rapid succession, how you gotta reach customers and stick out when everyone is breathing new stuff to buy?
Tough…but all that new shit must be coming out of people’s ears already, no?

1 Like

Hmm - I can’t remember the manufacturer. But I remember seeing a video from a german audio-tech manuafacturer. They had fantastic test-automation.
The mainboard was mounted in a testrig, and they had automated testing on both a component-level as well as high-level functionality.

Consider that getting getting hardware returned from customers is very expensive and time-consuming. So it makes sense to really test everything.



Fair enough … I’m not familiar with firmware/hardware development. But would you be happy being responsible for a product and continuous deployment of firmware without some QA over the whole thing ? The ‘whole thing’ in this case meaning turning some knobs and pushing some buttons.

I guess it’s possible.

EDIT: Ah … I see I overlapped with @synthbie

1 Like

To make Continuous Deployment work you need great automated testing, and the ability to roll back instantly if something goes wrong.

Testing hardware is tricky, and rolling back when you don’t own the hardware it’s deployed to would be interesting.

And there is usually a lot of inertia to overcome to change to a CD process, especially if there is one dev team currently switching tasks between all the different products Elektron supports at once.

I think it’s easier said than done.

And much as I love open source, I don’t see how Elektron could stay in business that way. Their hardware is nice, but not nice enough that it could support the whole business.


I don’t. Assuming an instrument is released with the features announced and free from bugs, I never expect a single update after that.

In reality, hardware isn’t released with all features announced nor is it bug free, but that’s where my level of expectation is. That some go out of their way to update and sometimes change the instrument through firmware is a fantastic icing on the cake that certainly sets some apart from others, but it’s never something I presume.

You got Synthstrom, Novation and Elektron in the update corner, setting the standard for what new firmware can provide. You got MFB and Sequential (mostly, and not counting the Tempest) in the other corner, and their instruments are equally great for what they do, updates or not.


I’d say we need good, stable and feature complete products from day one. Generalizing continuous deployment in music instruments will only lead to more incomplete machines being released and later abandoned.

hardware isn’t released with all features announced nor is it bug free, but that’s where my level of expectation is

I couldn’t agree more. The software dev mentality in hardware stuff has spoiled too much stuff already. Also… #Overbridge ?

Make the firmware opensource is not really interesting if the company is not willing to provide good (and free !) developer support (tooling, documentation, etc). That costs money.


Yeah, that’s what I meant. A good, stable and feature complete product should also lead to longer life cycles, no need to release product after product after product to stay relevant.


I find this cycle of half complete products and constant firmware updates/requests entirely fucking annoying. I’m really moving away from gear that sits in this model and more towards things that are pretty much the finished article on release. They’re musical instruments, not mobile phones.
I understand that things can be improved and that it’s nice to add cool new features without having to package them in a new product, but it creates too much expectation and entitlement, too much thinking about what we want, not what we have.


Knee-jerk response here: I def don’t want this. CD is fine for web software, in which the user is largely unaware of the “installation” process (downloading and running in their browser). The browser creates a sandbox around the software, limiting its interaction with the OS. Fixes can be delivered quickly, features tested (users experimented on) etc.

Hardware (what firmware operates on) is the basis of the running machine. If the developer makes a mistake, that could hose the machine. CD promotes short release cycles: no matter your workflow, bugs creep out.

Also, it’s in the name:
Hard: almost impossible to update
Firm: difficult to update
Soft: easy to update

Personally, I want my hardware to work for months or years, completely disconnected from the network, before thinking about updates.


Yes, apparently

I think we only tolerate it with mobile phones because we would pay ongoing costs for the connection anyway. The handset cost just slips into the monthly outgoings alongside something we can’t argue with.

Imagine if your washing machine, oven or air con needed upgrades? The horror!

1 Like

Well, as already stated above, the term continuous deployment doesn’t fit in this context, because Elektron has no control over the hardware for automated deployments/rollbacks (+ automatic detection if a deployment is bad / not just wait for users complaining).

In this case it would be a kind of “rolling release” mechanism, which is an absolutely pain-in-the-ass for development, support and the user base.


I’m not sure why some of you think that Con. deploy/deliver/release == bad quality?

Of course everything should be properly tested before a release - so let’s start by agreeing on that term :slight_smile:

And it is possible to structure the firmware to handle updates more like an app on your phone - so rolling back etc. is a lot easier and prevent you from bricking the device.

About finalized products from day one - I think that is a good thing, though unrealistic. We have seen a lot of HW devices the past years, which has benefitted from firmware updates over the years. Adding new features, demands and requests that was not identified on launch time.
I do agree that a pitfall to avoid is the release of unfinished products, at we see it on software especially in the game industry.

And I disagree that hardware today has to be hard to update. You can do it very smoothly today. You just have to structure the firmware container to handle this more smoothly than you would this 20 years ago. And companies do.

Thanks for all your thoughts on this subject. I think it’s interesting to hear all the different perspective on this matter :slight_smile: