dimatura

I agree with everything you're saying, but if you consider that this is a single-person company, the "hardware is as hard as you make it" statement makes sense. He saw a need, found out that it would be feasible to make a product to fill that need with very simple hardware, and chose to make the product. If solving the problem would've required hardware outside beyond their budget or skill level to make then presumably they wouldn't have pursued the whole project. Which I guess is sort of the point, but of course the title of the blog post doesn't really convey that.

I think "hardware is as hard as you make it" would've been a better title. The author made the smart decision of keeping things very simple on the hardware side, and that happened to be possible for the kind of product he wanted to make.

Interestingly I've heard a very similar story and sentiment about hardware vs software from another single-person maker (also a software engineer by trade) of a hardware product, also in the music space. And this one was comparatively a more complex product on the hardware side, and did face some supply challenges during covid and tariffs, forcing at least one redesign and price raise. But in both cases, I'd say they made smart choices about keeping the hardware simple. By not pushing the envelope on that front they gave themselves the freedom to invest a lot of time and effort into the software. But not every hardware product is like that (which the author also does acknowledge).

Yeah, I think a lot of the "hardness" of hardware is of a different flavor than software. The author mentions how many lines of code are in the software, but that really is more of a symptom of something that makes software "easier": you have way more flexibility to iterate, and try new things, at a relatively low risk and cost, even if it's embedded software (at least for non-critical applications). Hardware is just more unforgiving. There's no cheap way out of the kind of scenarios you mention.

They are simpler and can be read by more devices, especially legacy devices that are still pretty widely deployed. Other than that, not much to say in their favor. They have lower data density compared to 2D codes such as QR or datamatrix. Many linear barcode symbologies have weak or nonexistent error correction capability. But often you don't need that extra data, and the cost of changing processes and equipment to upgrade to a new barcode format is seen as not worth it.

Very cool work - refreshing to see a of different approach. I learned about Kuramoto oscillators many years ago from a book called Sync, by Steven Strogatz, which I highly recommend.

There's also git-annex and iterative DVC. I used xethub a fair bit (was the earliest user, in fact) and I thought it was better than git annex, git-lfs and DVC, but still did start to struggle past a certain size. I think part of the problem was just git itself, and the compromises required to have a hybrid repo. So I'm happy to see this vcs doesn't use it. xethub did start shipping a version of their product that did not use git but I didn't get the chance to try it. I've also tried oxen and it wasn't bad at first, but soon ran into some weird issues with the repo state which I didn't really try to debug. It is clear to me at this point, given my experience with all these systems -- none of which I've been 100% happy with -- that "git for data" is a nontrivial problem.

Of course it can. Is it good at it? I guess we'll find out, for sure people will try (I might if I get some spare time). At a glance some of the tech used resembles that of xethub (of which I was a user, until they got acquired by huggingface), which was marketed towards AI/ML/data science (to version control data/models/etc).

Yeah, that's the main challenge in research. Once you get immersed in an area, it's not that hard to come up with ideas that haven't been done before. It's also not that hard to do things that improve the performance of some method or system, at least by a little. It can be fairly hard to do things that are both novel and actually useful.

(I'd give that symphonic cycle a listen though).

QOI supports a VERY limited set of use cases compared to jpegXL.

Seems like there's some overlap with the iceoryx project https://iceoryx.io/

Not a bad idea, seems like data that would be be easy to monetize if it took off.

I usually feel the same when starting something new. The "STUFF" is annoying and often feels like overkill when a project is new and minimal. Installing/building ROS, the package boilerplate, etc. And often I can get away with more minimal alternatives like just a single (possibly multithreaded) process, or multiple processes with a simple IPC. But then again I often end up wanting a lot of the extra stuff you get with ROS like the bags, the viewers, the cli tools, etc. LLMs help on both fronts though - they're decent at making DIY versions of ROS-like functionality, but they're also pretty good at handling the ROS boilerplate. (Which is one area where I'd see peppyOS being a severe disadvantage).

Yes, we were on the starter $6 plan. The feature we got messaged about was SSH management, iirc.

I think how it works usually is that they let you use the features from higher tier plans than the one you're on; once you use them enough they send you an email asking to upgrade. That's what happened to us and I've seen other users mention it. Not sure how I felt about it, OTOH maybe it was less friction than explicitly subscribing for some "2 weeks free trial" or whatever but OTOH it did feel weird and unexpected. Anyway, we felt the extra features were worth it so ended up paying.

Yeah, they're not direct replacements. I think both models have have their pros and cons. In fact I tried both around when covid shutdowns started (server being in the office, me at home), and liked zerotier better; it was faster, and a more generous free tier. But now tailscale has won out for a couple of reasons; the main one, it's simply less flaky for us on macOS, especially for devs working overseas. No idea why and maybe there's simple fixes (that don't involve repeated connections/disconnections, hopefully). The other, tailscale has a few extra things that are nicer and easy to use like identity-based ACLs, funnel/serve, magicDNS, ssh management, etc.

Our company pays for the premium business plan, $18/mo/user. You have to pay for at least the lower tier plan once your team grows beyond a handful of people. And there's several quite useful features (though maybe not essential) on the premium plan like serve/funnel and SSH.

On the other hand, I do wonder about zerotier. before tailscale we used zerotier for a few years, and during the first 3-4 years we paid nothing because as far as I can recall there was nothing extra that we needed that paying would've gotten us. Eventually we did upgrade to add more users, and it cost something like $5/mo (total, not per user).

About 5-6 years ago, I worked a fair bit on an iOS app, primarily in swift (there were some obj-c and C++ bits). Until then, 90% of what I had written was either C++ or python on Linux, and I had never worked on a mobile app and had barely used MacOS (or iOS for that matter, I've always had android phones). From that experience I had an unexpectedly favorable impression of the swift language. I thought the ergonomics of the typing system and error handling compared quite favorably to C++, with better performance and safety compared to python. I didn't really like the Apple frameworks though, it felt like they were always making new ones and the documentation was surprisingly poor. Nor did I really gel with XCode (which is virtually a requisite for iOS development) or MacOS itself. But I actually liked swift enough that I give it a try outside of ios for a few test apps. Unfortunately, at the time swift outside iOS wasn't really mature and there wasn't much of an ecosystem. Not sure how much that has changed, but these days I'd probably reach for rust instead.

This is neat! It's a bit amusing in that I worked on a somewhat similar project for my phd thesis almost 10 years ago, although in that case we got it working on a real drone (heavily customized, based on DJI matrice) in the field, with only onboard compute. Back then it was just a fairly lightweight CNN for the perception, not that we could've gotten much more out of the jetson TX2.

I preordered the hardware version sometime before it was released. At a $50 price point, I thought it was worth a gamble. I wasn't disappointed! It's more of a hacker's device at the moment - for better or worse - but it's fairly powerful under the hood. AMY is a very impressive synth. And the device is clearly a labor of love from the creator.

PNGs of screenshots would probably compress well, and the quality to size ratio would definitely be better than JPG, but the size would likely still be larger than a heavily compressed JPG. And PNG encoding/decoding is relatively slow compared to JPG.

Yup, when reading this I immediately thought of jsmpeg, which I'm fond of.

About eight years ago I was trying to stream several videos of a drone over the internet for remote product demos. Since we were talking to customers while the demo happened, the latency needed to be less than a few seconds. I couldn't get that latency with the more standard streaming video options I tried, and at the time setting up something based on WebRTC seemed pretty daunting. I ended up doing something pretty much like JPEGs as well, via the jsmpeg library [1]. Worked great.

[1] https://jsmpeg.com/ (tagline: "decode like it's 1999")

"worth the money" is hard to say, especially for devices like these where the value is not really so much on the plain features as much as a more subjective factors like the design and the UI. I would say that purely based on features - probably not, especially with post-covid pricing. There are more powerful iphone or android apps for much less. Behringer, and to some degree Korg and Roland offer lower-end devices for not much more that ultimately might be more useful and usable. But, I do own a couple of these little guys and they're fun. I wouldn't call them "jokes", but calling them "toys" - in the good and bad sense - would probably not be a stretch, even if you can get some nice sounds out of them. I used to keep a couple on my desk and just jam a little with them as a distraction.

There's a fun podcast by Arman Bohn/Distropolis (who himself has made some cool small-batch hardware synths) where he interviews makers of small hardware synths, https://open.spotify.com/show/30USGHPeGQ9ZyWQDyRnfcv might be of interest.

were you using single cycle waveforms or longer samples? in the former case, I guess there's not much to it, you just cycle through the waveform (in which case the waveform you choose would usually start and end at a zero crossing by construction, like sines, triangles, etc - or, if it does not, well, that will just create extra harmonics that might or not be desirable). For the second case, it's more subtle. Most samplers that implement this feature will assume correct loop points (usually, but not necessarily at a zero crossing) are chosen manually by the user. Some of them implement cross-fading at the looping point to make that more forgiving, but that may be CPU/RAM intensive for some devices. If you're referring to small clicks you may get at the start and stop of sample playback, it's fairly common to use very short (ms or less) fade-in/fade-out to avoid that. There's a lot of books out there, but the main one I've read and enjoyed is this one, that happens to be free: https://cs.gmu.edu/~sean/book/synthesis/. it's more of a textbook than a cookbook.

Whenever I feel like doing that I just use "uv pip" and pretty much do the same things I'd do when using pip to messily install things in a typical virtual environment.

There's definitely a "rich get richer" effect for academic papers. A highly cited paper becomes a "landmark paper" that people are more likely to read, and hence cite - but also, at a certain point it can also become a default "safe" or "default" paper to cite in a literature review for a certain topic or technique, so out of expediency people may cite it just to cover that base, even if there's a more relevant related paper out there. This applies especially in cases where researchers might not know an area very well, so it's easy to assume a highly cited paper is a relevant one. At least for conferences, there's a deadline and researchers might just copy paste what they have in their bibtex file, and unfortunately the literature review is often an afterthought, at least from my experience in CV/ML.

Another related "rich get richer" effect is also that a famous author or institution is a noisy but easy "quality" signal. If a researcher doesn't know much about a certain area and is not well equipped to judge a paper on its own merits, then they might heuristically assume the paper is relevant or interesting due to the notoriety of the author/institution. You can see this easily at conferences - posters from well known authors or institutions will pretty much automatically attract a lot more visitors, even if they have no idea what they're looking at.

Ah, so that's why the camera seemed familiar, I have a couple of the luxonis cameras around the office :). Re: kiwi, those are good points. Thank you for the answer!

Hi, I am currently considering a Lekiwi build but I am intrigued by Mars. Outside of the need for external compute, what issues did you find with SO101 and Kiwi?

Also I am curious about a couple of the parts, if you don't mind sharing - are those wheels the direct drive wheels from waveshare? And what is the RGBD camera? (Fwiw, even if it's hefty the MARS price tag seems fair to me).

Seems like a corporate version of the "buy vs build" question. If it's true that the goal is to become more approachable to students and hobbyists (which personally I think would be a good idea) - then Qualcomm must've evaluated both options and decided "buy".