an-unknown

Except that's exactly the point: if you do this in your spare time, the development time is essentially "free". The only things that cost money if you do it in your spare time are the actual materials / PCBs / components / energy. And that is in fact rather cheap, provided you have the necessary skills and tools.

Since this whole post was about a Teenage Engineering hardware module originally, which has a strong focus on the case: if you own / have access to the necessary tools already (e.g. lathe, milling machine, …), it's a bit time consuming but not exactly expensive to build something similar. Sure, e.g. aluminum costs money, but together with the electronics I'd be surprised if you really spend 1200€ (price of the TX-6). Of course in that case it wouldn't really scale if you wanted to produce more modules in the end. For completeness, the TX-6 page specifically mentions the ADCs and DACs used. If you check the (current!) prices on mouser/digikey, they are ~5€ for the 4ch ADC chip (you'll need 3), ~15€ for one of the DAC chips and ~13€ for the other one. Then maybe add some fancy STM32 microcontroller for another 15€ and you essentially got the digital part already, excluding wireless connectivity. You'll still need a few analog components, the faders, the switches, connectors, and a display (probably the most expensive part). Feel free to guesstimate what the complete electronics and aluminum case would cost, but as I said, I'd be surprised if you get even close to 1200€, even if you need a 2nd revision of the electronics.

There are also various examples of people building e.g. clones of Moog synthesizers like the Minimoog (including keyboard, wooden case, …) in their spare time, for less money than what the original Moog synthesizer would cost.

> The trouble comes when it absolutely will not, because the sound of the 'vintage digital gear' is heavily influenced by the primitive DACS and typically non-miniaturized circuitry putting out a relatively low-bit sound with some serious beef to it.

The real question is if you want to accurately clone "vintage gear" or if you want to have something modern which is only somewhat "inspired" by "vintage gear". If you really want to create an accurate clone, sure, this is hard and potentially not that cheap, since it might require multiple hardware revisions before you're satisfied with the result. But if you only want to build something similar, which obviously won't sound exactly the same as the "vintage gear", then it's cheap and easy to do. Also keep in mind that you totally can get e.g. 8bit DACs or 12bit DACs if you really want. Even with "variable sample rate", like what some old digital samplers did. If you then play around with different interpolation algorithms, because modern microcontrollers are fast enough to allow you to do this, you'll get a sound that's surprisingly similar to "vintage digital gear". Sure, it won't be e.g. an E-MU Emulator, but does it really have to be one?

Interestingly enough, it seems like the KORG wavestate is actually based on some Raspberry Pi, according to KORG's github page, so you can definitely get less than 40ms latency and no stutter. And yeah, Teensy or even FPGA evaluation boards can get you very far, since software development in your spare time is "free". If you search the web, you'll find many examples of such projects. For example I remember some FPGA based project with iirc a small ~50€ Spartan-6 eval board which implemented a fancy 32 voice 6op FM synthesizer.

If you actually build one yourself (not just limited to this particular mixer, but also e.g. analog synthesizers, FM synthesizers, samplers, …), you'll be surprised by how ridiculously overpriced almost all of the available audio hardware really is. The sad part is that in many cases your prototype will be cheaper than the commercially available audio hardware.

In practice you'll probably skip the "and bring it to market" step though, because usually you'll start such a project because you wanted to have a specific mixer/synthesizer/sampler/…, and once you have it on your desk, the next project usually looks more interesting than spending the extra time to sell whatever you just developed.

Back in the day, it somewhat made sense that polyphonic synthesizers were expensive, since the electronics itself was expensive. Today, if you have a few weekends time, you can rather easily design your own custom analog polyphonic synthesizer in e.g. Eurorack format, manufacture it for something around 30-50€ (e.g. using some Chinese PCB manufacturer + their SMT assembly service), and the resulting module will outperform modern commercially available modules that cost multiple times more (think of a factor of 10x for the price difference).

It's even crazier if you look at digital synthesizers or samplers. Remember the E-MU Emulator from 1981, which cost more than $8000 when it was released? Today, a cheap 5€ microcontroller together with a 2€ DAC will give you more of everything already (more polyphony, more RAM, higher sample rate, more resolution per sample, stereo output instead of mono, …).

In many cases it's not necessary though. Most "pro" audio interfaces support MacOS because they are "class compliant" and therefore don't need extra drivers on MacOS. You could also say "no major audio interface company releases MacOS drivers".

Linux should support all these "class compliant" audio interfaces too, but I can't remember if you need extra software (like JACK?) for this.

If you were thinking about e.g. Dante for proprietary protocols, then of course there are non-proprietary protocols too, like e.g. AES67. Alternatively, if you prefer a protocol at a lower level / without IP, then AVB/TSN is another standardized protocol suite. However, AVB/TSN usually requires special hardware support in the network interface cards and switches to assist with QoS and to meet the timing guarantees.

What's missing here is type information. This is the reason why the decompiled code is quite unreadable. How to solve this: try to figure out what these missing types (like structs, arrays, ...) are, by looking at how the code uses the variables. Then you define these types in IDA/Ghidra/..., and this will already give you decompiled code that's much easier to read.

PlaidCTF 2020 had an interesting challenge, where you had to write a minimal 64bit shared object file which had to spawn a shell when preloaded to any (dynamically linked) program. There are write-ups describing how people did it: https://ctftime.org/task/11305

Naturally, the files from that challenge were bigger than the minimal ELF file presented here, because dynamic linking requires more sections.