Firmware - Continuous Deployment

I swear I wouldn’t even complain I’d just quietly take the win. It’s kind of funny in a frustrating way. One connection that is actually universally agreed upon somewhat unintentionally across devices globally that remained completely unchanged for generations and then one day some intern thought “hang on a minute…” and fucked it for everyone.

Definitely agree about being connected to a cloud. I never really got why splice is on my MPC. It’s a sampler lmao you could sample literally anything. You could plug it into a TV, a shitty radio, a cassette player or literally anything and make unlimited beats forever. Where’s the fun in splice? At least hoard samples like a normal person

4 Likes

Agreed! The device should not tell you there is an update ready - never.
Keep this information on the Elektron website and in the newsletter etc.

As I said, the device should not be on the internet :slight_smile:

1 Like

I’m probably going a bit OT now but it still staggers me that Microsoft were allowed to deploy updates that prevented the user from using the computer until the update had been downloaded.

But then a lot of things about Microsoft stagger me, not least their prevailing dominance in spite of their mediocrity when compared to long gone competitors.

1 Like

My Octatrack is probably the last piece of gear I’ll own that has firmware updates, and I’m fairly sure there won’t be too many of those to come. Everything else I own/want seems to be pretty much feature complete from day of release (Lyra 8, DFAM, that’s sort of stuff).
I owned a Digitone for 3 years, only updated the firmware when I decided to sell it, was a massive ballache as I don’t use computers ever, so had to spend half a day waiting for Windows to update seventy eight thousand times before it was ready to update my Digitone, which sounded pretty much exactly the same after the update.
Any gear that has to have it’s firmware updated more than once a year is not going to find a place in my house, I just don’t see the point in it. Maybe it’s because I’ve never really used computers, so I’ve never really lived too much in the world of updates and obsolescence and all that shite.

Or maybe I’m just a miserable prick.

4 Likes

No, computer operating systems ARE shite.

2 Likes

Right?

Like if you pulled some from 2001 and showed them windows as it is now they’d wonder what sort of apocalypse befell humanity that they could have gone so far backwards in such a short while.

3 Likes

This.

Is the sole cause of all humanities problems.

3 Likes

That escalated quickly! :smiley:

2 Likes

This was/is literally my job :smile:
I used to work with hardware/software, now I purely work with software (hardware is a PAIN).

CI is absolutely dependant on a good solid set of automated tests. The idea is that when a developer commits a change, everything runs automatically to build, test and release that change to ‘an environment’ with no other input required.
That is easy when you are a company such as Amazon or similar (apparently their apps are updated with new versions every minute? That seems excessive to me, but depends how much is included in that as they have a LOT of apps).
When you are dealing with hardware this becoes much more tricky as it can be tough to connect/install/disconnect the devices automatically as part of a software build process.

The biggest issues would be:

  • How would you want the updates to occur? Every time you connect it to a computer? How would they then implement that?
  • What if something is missed/incompatible or updates aren’t performed sequentially (still an issue with the current way, but easier to test for), they could ed up wiping projects, have compatibility issues etc…

I would assume there will be a fair amount of manual testing involved in all their product releases, which takes time, so lends itself far better to longer periods between updates, mainly out of necessity.

2 Likes

I used to look forward to macOS updates. When they were a product of their own which you paid for, they were user centred, interesting and often useful. Now I avoid them. They’re mostly just vehicles for the whimsy of the company execs retirement plans.

3 Likes

The “reason” being - that already stupidly slim and flimsy thing you carry around and stare into all fucking day, like an addicted zombie, well we want to make the next one even slimmer and more flimsy, so if you want to say anything to the handy headphone socket say it now, because well, spoiler alert, it don’t make it next season, on account of it takes up too much space.

I just want to know who the fuck wants a phone so slim, apart from a vacant twat who delights in showing everyone how slim their phone is, their dad probably used to do the same with his calculator in the 80’s.

2 Likes

They are purely there to make your hardware slower so that they can sell you a new device :wink:

1 Like

I sure hope that somewhere down the line Apple and Microsoft get their asses handed to them, the same way thank banks ripping people off did, or the current diesel emissions thing, where consumers can claim against them.

I designed and built something similar for a previous company, using pins to connect to different points on the PCB to measur inputs/outputs while a program controlled the device over USB.

They are generally aimed more at confirming the PCB has been manufactured correctly, rather than testing software (you would have to confirm the test software works correctly with the updated firmware which really has to be manual, unless you start getting test automation for your test automation).

I have seen others with servos pressing buttons and running through tests, but I imagine that would be a nightmare for any of the Elektron devices. I certainly wouldn’t want to have to make it, much less write the tests, myself.

2 Likes

I think that ends the “is it possible” discussion … let the “do we want it” discussion continue . :wink:

2 Likes

expected?

why?
I think the manufactures responsibility is to provide updates where needed - I think its up to them to decide how they do this in a cost effective way.
are you willing to pay for the extra costs and investment this entails?

for what?
just releasing stuff ‘continually’ doesn’t mean bugs get fixed, features get developed… that still needs the same development effort.

sure, if you are Apple/Microsoft/Google and have hundreds of developers working independently, then you release continually, since you cannot schedule all of these developers release dates.
for smaller teams - co-ordinated releases are more appropriate.

is it appropriate?
imagine all manufactures went this way (as its now ‘expected’ :wink: ) ,
even with 10 instruments, you’d spend a ridiculous amount of time keeping things up to date.

‘oh, but id only update for to get a bug fix’ - so you have to check every log, to see if the bug you are interested in is fixed,

this is pretty much why continous deployment requires automatic updates (e.g. apps stores) because its too monotonous for users to keep having to check to see what updates are available.


CI/Automated testing is great - but has little to do with continous deployment.
to start with it doesn’t cover any kind of usability testing.

3 Likes

…never underestimate one developer hours’ pricetag…

…coming up with a concept…is fun…
…planning and calculating the collection of all parts needed for assembling…hard job but fun…
making the firmware work smoothly…tough and smart cookie job and end of the day no fun at all…
cutting out bugs, implementing further improovents, fixing further bugs, implementing further improovements, finding further bugs, cutting them out again, coming up with final improovements, finding further bugs, fixing them…it’s endless…and priceless…if u don’t manage it with lot’s and lot’s of care…

2 Likes

Strictly speaking, I suppose automated testing is not needed for CD, all that you need is a comprehensive, repeatable, and relatively inexpensive (in time and money) testing methodology for regression tests. Usually, that rules out manual testing.

What does ‘continuous’ mean to you ? To me it means “once the developer finishes, if it passes all the tests, then it gets deployed” … I think most people would interpret that as automated tests.

I don’t think usability testing has any relevance here, making sure you have something that’s usable is

  • a massive upfront design cost before initial release
  • a consideration in the feature development phase for new features.
  • a concern for the developer when bug fixing

In other words, not a consideration for continuous deployment, which is what happens when the developer is finished.

IMHO.

EDIT but I agree with you that usability testing is an example of stuff that needs to happen to a degree in any development and can’t be automated, of course.

1 Like

OK, I really need to mentally sum up things now :slight_smile:

A lot has been said about:

  • Speed vs. Quality?
  • Types of tests?
  • How to get the firmware update?
  • Do I want it or not?

And thinking of it, maybe discussing DC, tests etc. is not relevant, without agreeing on what problem we are trying to solve here :slight_smile:

Maybe, the real question I should have asked in the beginningshould have been: Do you want more frequent and smaller firmware updates? And how can we get this?

Personally, I would really appreciate more often releases (that I manually install as I do today). Actually I would preferer accumulated releases from Elektron when ever a feature, bugfix or improvement was done - as in ready to release and tested etc…

Maybe or maybe not, would CD be the right approach here. I guess only Elektron would know. But, it could be a possible right solution for bringing more frequent updates to the customers.

Companies can’t even do “deployment” to the target devices. “Deployment” means getting it onto the device.

Continuous “release” is achievable, but I still dispute it’s necessary or even useful for the kinds of devices we’re mainly talking about. And if it’s not useful, it’s almost certainly not sensible to build a business around it.

2 Likes