cpdt

And to elaborate on how the error message relates to this: std::addressof takes a reference which also can’t be null. So when you dereference the pointer you’re actually turning it into a reference (or binding the reference to the pointer, as the error message says).

From what I've heard, when dubbing shows they normally adapt the translations for the dub to fit better with the character's mouth movements and to make it more 'idiomatic' in the target language, but the subtitles keep the literal translation. It would be interesting to learn why, I find it drives me crazy as well.

I think jqbx.fm is what you’re looking for. Only works with Spotify Premium from what I’m aware though.

Just had a look, and it turns out that's including running LLVM's optimizer as well, which takes roughly half the time. It's basically doing the equivalent of -O2 currently. That's probably more aggressive than what's needed, but I haven't taken the time to fine-tune it yet.

Other than that, you're right that it might be a bit high. There's very likely parts of the lowering code which can be optimized, I just haven't had the need to yet.

I'll look at writing that blog post soon then :)

Just did some proper testing on a reasonably complex project, looks like I was about an order of magnitude off (to be fair it was 2AM here at the time, and I wasn't reading the numbers right haha). 30-40ms is still fast enough that you don't notice for the most part though. For this specific project, it breaks down roughly like this:

- ~1ms to build the new MIR based on the editor state

- ~5ms to process/run passes on the MIR (this involves some funky graph traversal which could very likely be optimized a lot)

- ~12ms to generate LLVM IR

- ~14ms in the LLVM JIT

In a project that makes good use of groups (nodes that contain a surface inside and then expose some controls back out) I'd expect this to be lower, since we only need to perform those operations on the surfaces that change.

Yes, this was one of the initial inspirations for the design of Axiom! I never actually had the chance to play with it though... would be quite interested in learning how it works.

Yeah, you're not wrong that it's pretty dark. I have done a bit of work recently on lightening up (it was even darker before!), but I'll definitely look at brightening it further in the near future.

Yeah, it works quite well. In my case, I used ‘ExternalProject_Add’ to run the builds through Cargo, then setup a static lib target with that as a dependency, linking to the files built by Cargo and a few system libs it expects. From there you can treat it like any target in Cmake, and it just works(tm).

Edited for clarity

I haven't actually properly played around with PureData (other than watching a few videos on it back when I started this project), so I can't really comment too much on how that compares.

I was initially worried about how interactive compiling would be, however it turns out (at least with the projects we've tested it with so far), it's pretty easily able to keep up with around 3ms from a modification to codegen being complete. The LLVM IR we generate is pretty simple which helps, and we also try to only recompile as much as possible by putting everything in separate LLVM modules (hurts runtime performance a bit since we can't optimize across modules, but it doesn't end up mattering too much).

The graph operates per sample - we really needed that feature to be able to do feedback loops, for things like FM synthesis.

Edit: I started adding in an explanation of Axioms architecture in the hope that someone with knowledge of similar projects could chime in, but it was getting quite long... might look at writing a blog post on it sometime soon, if people would find that interesting.