I followed the code path when you change the cabinet type, and saw it write some values to the DSP based on a 2D array of doubles, one for each cabinet, each with 41 values, and it was processing them 5 at a time. Looking at the values, they were all in the range -2 to 2, and were very reminiscent of biquad filters I had learned about in another project (https://mforney.org/blog/2025-06-06-babyface-midi-protocol.h...) which was still pretty fresh in my mind.

I tried plotting them, and I got something that looked right when I inverted the denominator coefficients. I guess this is fairly standard practice because then the difference equation is all positive sums and it can be implemented with a bunch of multiply-accumulates.

However there were still some discrepancies in overall gain between different types (most lined up, but a couple did not). I saw another array of integers indexed by the cabinet type that had negative values, most with -23 but a couple with -12, which I figured must be a decibel gain correction. It was only after accounting for that and seeing the final graph in the post where everything lined up and looked plausible that I was pretty sure I had it right.

So, mostly just general familiarity with digital EQ filters and a bit of luck.

Unfortunately there were no firmware updates for the THR10c, so the only way to get the firmware is to dump it from the device.

git -C /src/oasis pull && samu commit && doas git -C / merge

The first command pulls updates from the source repository, the second command builds a new filesystem tree and commits it, the third command merges that commit into your / repository.

thanks for oasis!

Sorry for the confusing wording. I meant that oasis has more similarities to a BSD than a typical Linux distribution.

I've updated the README to be a bit clearer.

Good work.

> A simple way to fix this would be to shift c by 24u, "(c << 24u)" which would promote both values to unsigned int

This works for most arithmetic operators, but not shift: "The type of the result is that of the promoted left operand". The type of the right-hand-side has no effect on the type of the result.

To fix this, you'd need to cast the left-hand-side to a type that is wide enough.

Yep, you can install firefox via pkgsrc or nix. Due to the complexity of the modern web browser and all of its dependencies, it is unlikely to ever be part of oasis itself.

Is a self-sufficient static build of Chromium or Firefox an impossible thing?

As of now I think it is, but it should be fixable. Something like Oasis might spur interest (and possibly a framework) for such work.

It's tedious and cumbersome to do so with C++, and with QT is a nightmare.

There is rudimentary hardware acceleration for certain older GPUs that I own in wld (intel at https://github.com/michaelforney/wld/blob/master/intel.c and nouveau https://github.com/michaelforney/wld/blob/master/nouveau.c).

But, for everything else there is only software rendering via pixman. I started working on a new library called libblit that will support amdgpu, and I managed to draw some rectangles and textures, but there is still a ways to go on that: https://git.sr.ht/~mcf/libblit/tree/master/amdgpu

> I was ever so slightly disappointed to see how manual the packaging is, with every .c file listed in each lua script. It looks quite maintenance-intensive.

I was worried about this, too, but it turns out most of the cost in just the initial packaging. Packages do not tend to change their build system very much in between releases, so updating is usually just `git diff` between the version tags, sometimes adding/removing a couple source files to `gen.lua`, and regenerating `config.h`.

I'm just one person, but I've been able to keep these 100 or so packages up-to-date fairly easily, while still spending most of my time developing my own projects.

> I was almost hoping for some kind of meta-build system which could parse automake etc. files and hoist the dependency graph into the main system build.

This would be amazing, but I think it is too difficult a problem to solve, especially with the huge variety of build systems (which are sometimes used pretty creatively). For some packages I get part of the way there with scripts or command snippets to extract source lists from the upstream build system. Here's an example: https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gens...

One of the main motivations for the oasis build system is that it is often very difficult to get the upstream build system to do what you want. It is very common for projects to ignore your CFLAGS or LDFLAGS, ignore special include/lib directories for dependencies, or have automagic dependencies (to borrow a term from gentoo) that can't be enabled/disabled explicitly with a configure switch. Also, most build systems don't work very well for building things statically. libtool will intercept your -static flag, hiding it from the compiler, and libraries which are dependencies of other libraries get left out from the linking command.

I suppose you could argue that, but it is not a package manager in the traditional sense.

My main point here is that once you build the system, there is no longer any notion of "package", just files that make up your root filesystem. There is no package database tracking which files came from which packages. Instead, if you want to add/remove/update a package, you rebuild the system with a different specification, and then sync the resulting tree it to /.

> Statically linking all the OS utilities to their dependency libraries, over and over again? Dear god that sounds awful.

Just curious, why does that sound awful to you? Are you worried that it will take a long time to relink the binaries? The oasis build system is incremental, so updates to a library only involve relinking dependent binaries, which is quite fast. Even a full rebuild from scratch only takes a few minutes (assuming you have the sources downloaded already).

If it's just the idea of relinking all the dependencies over and over again, note that with dynamic linking you do this at runtime every time you execute a binary.