 A few days ago, my groovebox, the #SynthstromDeluge, running the new and awesome community-built firmware, crashed, which was very cool. Not that it crashed, but what happened next: It displayed a colorful pattern on its pads. That's a stack trace. It's listing the last steps the code made before crashing. The devs have asked to be sent photos of these, to help them find bugs. I've pasted it on Discord, and there's a _bot_ that recognizes these images and decodes them into addresses! 50 comments
Each of the colored blocks of 4×8 LEDs represents a 32-bit address in the firmware, while the 2×8 section at the right is displaying the first 4 hex digits of the Git commit hash that's running. The colors represent different types of stack frames, if I understood it correctly. Devs then translate these addresses into the actual functions and lines in the code and can start to reason about it.  @dezwo I had my Deluge crash three times. Once with the stock firmware, twice with the community. I don't think that means anything. If I was performing live, I'd be hesitant. But I'm not, and the community firmware comes with _so_ many improvements big and small that I'd be missing out if I didn't use it. I don't regret upgrading. That being said, I'd love an "auto-save" feature, but saving manually every few minutes doesn't really hurt either. Let me know if you have any more questions. @dezwo Also, the community firmware definitely is the future. It has made lots of refactorings, which means that merging single features back to the Synthstrom firmware is hard or even impossible. I expect (and the community devs do, too, afaict) that the Synthstrom firmware won't see much development in the future. Instead, the community one is where features & bugfixes are going to be. It's already so much better than stock, and the stock firmware was already pretty good.  @dezwo @scy Dude, open source firmware has become a major factor for hardware purchase decisions. My linnstrument is open source, my norms shield, my axoloti synths. The m8 was promised open source when I pulled the trigger, but the maker seems to be too lazy to release openly. Some of the major innovations in synth hardware were all open source (mutable instruments, for example). I am saving up for a deluge. @tekknovator @scy I don't doubt that folks care. But forking and maintaining a proprietary code base is no small feat, so I was interested in @scy's experience (especially since he started the thread with an experience report or a crash and subsequent debugging). Anyhow, thanks for sharing your perspectives. RIP my notifications I guess :) If you're interested in the Deluge, I highly recommend it. The official website is https://synthstrom.com/product/deluge/ and https://youtu.be/aBeeDwukpTs has a detailed introduction. #Synthstrom is a small company with a great attitude. When they introduced the OLED screen to the Deluge instead of the 7-segment display it had before, they offered retrofit upgrades to all existing customers instead of trying to sell you new devices like pretty much the rest of the industry would.  @scy That's actually really cool and clever use of the technology for debugging! 😮 @dragonarchitect They also have debug logs via MIDI Out, but this requires you to actually start capturing them before the crash, which most people won't. Thus they needed to be able to extract the most important parts in another way. @scy Also, that photo paired with the bot's transcription of the debug log in lights gives me a clue about how that keypad is wired up as well as the possible endianness of the bytes, since that keypad is a 8x32+8x2 matrix. @dragonarchitect I wouldn't count on it, there's quite a bit of bit shifting going on in the source code of the crash handler. But I didn't look into it too much. @scy Fair! I'm just thinking out loud with a hypothesis anyways haha I have very little experience with reverse engineering. I see something neat like this and I start thinking of ways I might make it work. @scy That is an awesome and unexpected way to help developers. :-) I will make a bet that they had product management that fully understood what the developers wanted and supported the feature ... OR Some developer spent personal time adding the feature and didn't tell the PM because they wouldn't understand its value anyways.  @thunfisch Oh, I totally understand. I spent months comparing grooveboxes and then finally pulled the trigger a few years ago when Synthstrom announced (in advance!) they'd be increasing the price soon due to all the new features the Deluge got. I then didn't really use it for two years or something, because I didn't have (or rather, take) time to actually make music. Now, with #WeeklyBeats2024 going on, it's the first time this thing actually has to do something, and it's doing it quite well. @scy If my debugging was that pretty, I'd probably be better at it. Reminds me of reading the lights on a PDP-10. Pass the DECtape!   ¨@scy The community firmware has been very cool. Maybe some day we'll get time signatures other than 4/4ths. 😁 @abortretryfail Can't you already use the variable length of clips to fake pretty much any time signature? I just gave it a try for giggles and found some other things that get in the way. The lead-in when recording notes is still 4 beats, copy/paste end up totally misaligned, and the clip playback position in keyboard mode is confusing at best. @abortretryfail Okay I think I understand now. To be fair, support for anything but 4/4 isn't that widespread among grooveboxes as a whole, but I can see where you're coming from. The next version of the community firmware has a 7seg emulation mode btw, so you can convert your OLED screen back to the numeric style if you really want to :)         @scy I was looking at that and thinking... "That's a really interesting beat" but only just saw that you said it's a stack trace. Which really is amazing way to handle it. Crashing isn't fun, but having a crash that *might* be easier to handle debugging of is really awesome. |
Gregory's Server
@scy 🤯