dashersw

Ah, the cable arrived and I tried it. The problem is, the cable only works with USB2.0, High Speed devices, but ESP32-S3 is only USB1.1, Full Speed, so unfortunately it doesn't work.

There's an S3 audio board but there's no need, a real guitar interface is a much better option.

I do have a company, yes. Feel free to contact me at contact@playtaurus.com

Of course, what we are missing here is audio output :))) how are we going to listen to it? This S3 board has a tiny speaker, and I think for a demo it will work just fine, but :))

Great finds! I'm pretty sure I'll make it work with ESP32-S3 :)

I'm building one right now :) How much would you be comfortable paying for such a device, given it has a stereo jack input, a stereo jack output, a headphone jack, and a USB-C connection?

Oh I found one on Amazon.de and ordered. Will let you know :)

Thank you! I am surprised it doesn't work with iPad Pro. They don't ship to Germany, otherwise I'd buy one and try. If you have an ESP32-S3 device, I can help you with it if it doesn't work.

They all use underpowered DSP chips from yesteryear. ESP32 is a great platform, and P4 is doing even better. I have a prototype running 2 A2-full profiles, along with 10 other effect blocks, on a P4.

I believe we are starting the age of personalized hardware, and Waveshare & co are doing a great job at bringing affordable, multi-purpose devices our way.

Would love to hear your experiences if you try out this build.

One small clarification, this approach isn't really a "model conversion". Current pedals on the market quantify the entire model, so you are essentially running a separate model. Here I use the same weights, but only change the floating point representation. That's why the difference to A2-Full is basically inaudible. Mooer's NAM conversion, for example, has a null test peak at -8dB. They also need to do this because of the 44.1kHz conversion, so it's incomparable.

Thank you :)

It's really beautiful to touch!

That's literally the title of my blog post at https://playtaurus.com/blog/running-nam-a2-full-natively-on-... but no, it runs A2-full, because I wrote a custom kernel for it in assembly.

S3 doesn't have enough floating point processing power, so what I do is to split the model in two, run the model in series, and represent floating point values as block floating point, essentially compressing the floating point representations.

The null test peak sits at -60dB in the worst case, in 193 different NAM profiles I tested, which is basically inaudible. You can listen to the different profiles here https://playtaurus.com/blog/running-nam-a2-full-natively-on-... and listen to the difference between A2-full and A2-lite, vs A2-full and my approach.

Depending on your guitar interface, it's around 4-10ms. Some interfaces have really unnecessary buffers, accounting for very old and low power devices. iRig HD X has an unused buffer of 4ms in its firmware that I patched. As atoav said, you don't really feel it, especially if you play on headphones, it's like sitting 1 meter away from the speaker.

Because I wrote Gea Stack :) and CoyoPedal also serves the purpose of a demo app for Gea. The DSP is native code, most of it is in assembly. The UI is portable for any device. One small correction, Gea doesn't have a TypeScript runtime, it's all compiled to C++ ahead of time, so effectively all the code that runs on the device is native.

ESP32-S3 is a great USB host. I have a custom version where I use a Daisy Seed 3 as the ADC/DAC (it uses I2S for audio, not USB) that I built with around 4ms total latency. If you turn off the amp model (which is pointless, but) it's around 2.6ms. I also patched the iRig HD X firmware so its analog latency is around 1.2ms, practically achieving the same performance as the custom Daisy Seed 3 interface.

It's the author here. AMOLED is beautiful to look at. And you can stick this device on your guitar. Having said that, the same code can be compiled to any ESP32-S3, even headless boards, to use in a custom pedal (like the ones with Daisy Seed 3). CoyoPedal uses Gea Stack that allows us to target any device, including macOS and even the web, https://coyopedal.playtaurus.com has the exact same DSP and UI code built for WebAssembly.

Ah damn, this is a leftover from literally the first day of our Android target build. Of course it's native for Android, too. Will fix it ASAP, thank you!

Amazing questions, thank you for the careful read!

We should ship a compatibility matrix... at some point we were hoping to report test262 coverage for ECMAScript compliance, but we had to prioritize the release. Of course any of the typical web APIs work, including localStorage, and even so far as the Web Audio API (and we're working on WebRTC to make it cross platform. It's especially interesting to be able to build real-time communication apps, say, on an ESP32-S3, with just the web semantics).

In short, most app code stays inside the portable model. You need to know the target when you use host APIs that are constrained on small devices: blocking I/O, memory limits, file sizes, and of course you can combine it with native code for the target. I'm building a guitar effects processor, for example, where the UI is powered by Gea Stack but all the audio processing happens natively (https://github.com/dashersw/coyopedal).

On AI: yes, it's mostly me plus agents for the compiler. We have a team at Coyotiv that helps with everything else. I use Claude Code with Claude Opus as the main model and Sonnet subagents for parallel work, with a fair bit of Fable. I also combine this with whatever GPT model is available over Codex. During the past 6 months I've started working on the compiler, I've changed several model versions :)

What makes AI perform on a compiler:

Hard gates the agents can't argue with, like a diff gate that names every program whose output changed, plus conformance sweeps, a diary that captures past failures so they don't repeat, and treating a passing exit code as insufficient and the outputs get checked against Node.js behavior and unit tests.

The biggest differentiator for me is, even though I'm a pretty relaxed manager for humans, I'm a heavy micro-manager for AI. I read its thinking tokens and its code live and as soon as I spot something I don't like, I intervene and guide the model to the output I want to see.

It wasn't easy, Gea Stack in total I think burnt more than a million dollars in AI credits, and I've been working on it literally non-stop for 6 months.

It's ref counting, so most objects are freed as soon as the last reference goes away. Cycles are handled by a backup cycle collector using trial deletion (Bacon–Rajan style). Any object whose refcount drops without hitting zero becomes a candidate, and the collector traces from those candidates. In practice cycles are rare, and refcounting does almost all the work.

There were a lot of hurdles along the way and we solve them as we come across them. Keeping values native when JS uses them dynamically was a challenge. d = new Date(); d.foo = 1 is easy if you box everything, but then it's a slow interpreter (like some other projects in the field). So we had to invent a new mechanism; native types get a side table for extra properties.

Generics and union types were also challenging: one JS generic can need several different C++ layouts.

eval is limited: new Function runs on a small evaluator written in C++, and direct eval isn't supported yet.

We ran an experiment with Perry, you can read it here: https://geastack.com/blog-hono-with-perry

TLDR; it's 11x slower than Node.js and 23x slower than Gea Stack with Hono. With raw HTTP server, Perry is ~27% faster than Node.js and Gea is 3.5x faster than Perry.

Much appreciated. There's a lot to work on, and we initially chose to spend a bulk of our effort on the engineering work itself as it's the moat and the foundation to everything else. Everything else we can fix in time.

Having said that, I personally designed the logo and visual aesthetic and it serves a purpose. We believe in firmware freedom and hardware hackability, just like it was the norm in 70s and 80s. Of course it could have been executed better, but the current form is a specific choice after many iterations and certainly not low-effort. Too bad it reminds people of AI-slop, for an older generation it reminds other things.

We compared it to scriptc here: https://geastack.com/blog-geatsc-vs-scriptc

Heh, we spent 6 months writing and rewriting the compiler a couple of times and were just too excited about the final architecture. Thank you, simplified.

A plain number is a double, and then the compiler can prove it can be a 64-bit integer if the size is appropriate. The goal is to keep behavior parity with Node here. Loop counters etc stay double. But we also support custom types we introduced such as i32, which is crucial for embedded performance. And then of course we have proper typed arrays.

Regular arrays are dense, but we keep a presence bit for every element so we can identify sparse arrays and differentiate holes from undefined's. And finally, there's no Error.stack support right now.

Thank you, would love to grab some time later next week!

And just to clarify, of course, this limitation is only for "eval", not regular TypeScript :)

Most libs from npm compile fine, including Hono, and we are now working on Fastify and MongoDB native driver.

We had an earlier prototype with a full-stack Gea-compiled app with dynamic fallbacks, but I believe we can do better.

And yes, of course, we tried compiling TypeScript compiler to C++ via Gea Stack, but had to deprioritize to get the release out the door.

Ah, amazing project! Congratulations. I was just writing under another thread that we support any and unknowns in two different ways. First, most any and unknowns are lazy programming—if you trace the call graph you can prove they have concrete types, or used only in one shape. If we can't prove a type narrows properly, we lower it to a boxed dynamic value carrier so it doesn't block compilation. Like JSON.parse—for this we have a special syntax, you can do JSON.parse(x) as T, to define the type, and if you don't it becomes a dynamic value whose price you pay only for that site / variable.

We also have limited support for `new Function("...")` via a small evaluator written in C++ that parses and runs the generated body. We mainly built this for Fastify's generated routing functions so it doesn't support classes, asynchronous, destructuring, etc, but conditionals, loops, variable declarations etc work.

There is no "eval" yet, but the same support shape could be added for it too, as the mechanism is already there.

The approaches and the limitations are documented here:

https://github.com/geastack/compiler/blob/main/docs/EVAL.md https://github.com/geastack/compiler/blob/main/docs/DYNAMIC-...

As much as it would cost a native app. Say, on Mac, a plain AppKit app consumes 16-17 MB, gea consumes 18-20 MB, Qt consumes 25-35 (depending on whether you use QML or not) and Tauri consumes 58-60 MB. Tauri suffers a lot from all the WebKit dependencies, as its UI is not native but rather HTML rendered by WebKit.

It took us 6 months to build the compiler. We analyze literally the hell out of the call graph. We started with strictly typed TS, which is trivial to compile. Then we added a dynamic fallback for projects that have "unknown"s and "any"s, then we had several architectural changes which allowed us to inspect those "claim"s. If you think about it, marking a variable "any" is a lazy claim. If it's ever used in one place and in one shape (akin to duck typing), you can create a static struct out of it...

So there's no byte code, and while not every single dynamic language feature has a corresponding static compilation, the base is pretty broad. So much so that Hono, the web framework, with all its dependencies, compile just fine.

I understand and appreciate the concern. We've been working on Gea Stack for about a year now. Started with https://geajs.com, then decided to enlarge the capabilities. The current capabilities have been under development for the past 6 months. We are in the process of forming a new company around Gea, and already collaborating with multiple embedded device vendors, development partners and customers who are interested in the technology.

There's a broader philosophy of "firmware freedom" that we want to bring to the world. Practically, you should buy hardware for what it is, and run your own firmware on it. E-book readers and unlocked bootloaders in the Android world is doing a pretty good job at this, so we want to contribute to this movement by making the development of such solutions dead simple, both for humans and AI. Incidentally, TypeScript, JSX, and CSS happen to be the languages AI knows best.

So, it's an ambitious project with a real team behind it, with commercialization on the horizon.