"No, but I have seen the house that the project built, and it is terrific." ~ some Google director

The same goes for a binary protected by TPM 2.0, but the attacker would have to re-implement the protected parts. The defender's bet is that this should require too much effort/time/knowledge to bother.

So you can ignore the newly-enabled games in this proposal and you're not missing anything you had previously.

Actually, let me grab it. [...] Hmmm, better than expected. It works out of the box, but there's note latency compared to native apps. Also, zooming and text selection appear even when you don't want them. Janky for real playing, okay for a demo.

It doesn't have nearly enough power for proper circuit modeling. You might as well use samples.

You CAN get an STM32 to sound beautiful and fun (shout out MI Braids), but in 2026 that's available in VCV Rack for free.

Every chip? I bet it can't target analog chips, what with the pointer talk and all...

DRC/LVS/PEX/SPICE are deterministic, but the tools themselves are not without faults.

I'm getting 50x faster code with manual ASM. That's the difference between audio code that runs in realtime and code that does not.

The competing implementations use SIMD and native code, autovec works nicely there. I symbolically invert the LinAlg system at compile time.

You can either have performance (=write manual ASM for each platform), or portability, but not both.

What so-called "portable SIMD" libraries give you is "portable auto-vectorization". "Portable performance" is a global property of the algorithm. Relying on auto-vectorization will result in e.g. sub-optimal register spills in practice. The microbenchmarks will look great, though. ;)