A major consideration for any firmware where combinations of buttons and knobs change what is meant to happen. I’ve never worked with firmware, but it wouldn’t surprise me at all to find out there’s a lot of manual QA/regression testing to do with every update.
1 Like
Hell, how many of us though making music would be easy until we actually tried it?
(Also, programming for musical devices is optimization hell. All the requirements of embedded AND strict real-time performance)
7 Likes
I mean, it’s probably not impossible to write a test for it but for sure physical qa is tedious with these devices, I think just to test upgrading firmware from every existing version would be tedious aside from testing every button combo in the process… yikes.
1 Like
“firmware code is private.” True, but there are lots of things you can understand from the device itself. For example yesterday I was trying to understand better the inner workings of analog rytm (also based on some observations someone made on the other post about editing patterns). I did a pattern A1 using kit , mangled the kit, then moved to pattern A2 using kit 2, mangled the kit, then went to pattern 1 and kit 1 retained the mangled bits. So this means there is a copy in memory of kit 1… and when you reload the kit it overwrites it. It’s not a single temporary area of memory that works for the current pattern, because if it was like that going to A2 (kit 2) and then back to A1 it would have overwritten that. The patterns work slightly differently because when you switch patterns the pattern is overwritten, and if you go to A2 and then back to A1 you can’t go back to the previous version with [no]+[pattern]. So I don’t know if there is a temporary area for each pattern on just one for the active pattern.
It’s of course guessing, but you can do these kind of reasoning observing the outer behaviour of the device.
Another example: I believe that the 127 samples are in memory, but I don’t know if there is a limitation on the length of the samples (I should check the manual). If there is not, I would conclude that some sort of buffering and streaming happens, instead of there is a limitation would be probable that the entirety of the sample is loaded into memory.
1 Like
Sure you can make some inferences … but if you haven’t seen the code you still can’t really judge the effort involved in making a change.
3 Likes
I’m glad I can now link to this thread whenever somebody says a feature should be easy to code.
7 Likes
Of course, the estimation is always a guess, even if you read and worked on the code before. Even for elektron guys.
1 Like
I believe that machines are full of kids, running fetching patterns and counting trigs, there’s only so much they can do… have mercy!
3 Likes
Hofstadter’s Law: A project always takes longer than expected, even when taking Hofstadter’s Law into account
8 Likes
I see the opposite too.
It’s impossible to change, or write.
For instance the prevalent talk right now about the Waldorf Kyra. “It’s impossible to bug fix except by the original author, because it is done with an FPGA.”
That’s garbage too.
4 Likes
how about: “it’s easy to code! why don’t they make the firmware public so I can just do it!?!” 
5 Likes
So true!
Most people don’t understand how much red tape there is, many companies likely have licensed proprietary libraries or algorithms that can’t be open-sourced - e.g. the pitch and time libraries from either zplane/zynaptiq, or even buffer representations of waveforms, many companies license the Galbanum singe cycle waveforms, which are not openly redistributable. The toolchain to build and sign the firmware is also something most companies won’t want to give away freely, as there are some companies who like to make cheap clones of other’s hard work and r&d.
I love open-source, and wish more things were openly accessible, but this is just the money driven world we have to live in 
3 Likes
Please do … I’ve realised since starting this thread that if I do that it gets all passive/aggressive.
1 Like
I know nothing about coding, so I can talk as the average costumer.
Many people may say “It should be simple to code” only because everyday we download tons of upgrades for tablets, PC, smartphones, app… and so we may think: why should be so hard to implement a feature in my groovebox? Surely has to be easy!
At the opposite side, but for the same reason, when people is waiting in vain for a firmware update, they can imagine that it doesen’t happens because “it is hard to code”.
EDIT: obviously both assumpions are wrong.
As a professional software dev and team lead, I’ll say this: the person claiming “it’s too hard to code” may be right or may be wrong, but the person saying “it’s easy to code” is always wrong. On big projects, nothing is ever easy. If you think making some change was easy, that just means you don’t realize all the bugs you introduced yet.
20 Likes
Many people don’t appreciate the steep slant on expectations VC and private equity capital has had on our day to day lives.
5 Likes
you’re pushing it
4 Likes
15 years as a working software developer here, and 3 years at a well-known plugin developer with friends in various well-known high-end audio companies.
Generally it isn’t about hard or easy, it’s about what the value is for the time commitment and whether it’s part of a bigger picture. You don’t make software better by just adding more features. The software devs here will attest to the terrible and bloated but widely-used project management tools on the market as evidence of this.
Also, just because you want a feature doesn’t mean it’s a good idea, that everyone else wants it, or that it will actually solve whatever problem you think (often misguidedly) you have. 90% of the time people want a solution to a problem but they mistakenly think they want a feature.
20 Likes
OTFM. Anyone who has worked in enterprise software for any length of time has very real trauma associated with the words “it’s easy to code”.
12 Likes
Very, very true. Especially when that expectation comes from a layer of management a few levels higher than the coder/developer.
5 Likes