My late paternal grandfather told a tale of a fake airfield in WWII with a bunch of wooden planes in it, on which the opposing side (forget which was which) obligingly dropped a wooden bomb
TIL
Here's me live-editing a more basic patch (I hadn't implemented the resonant lowpass filter yet): youtu.be/isjAw9rz6FE?...
The intended endpoint is much cooler - a much more powerful DSL for defining patches, integrated MIDI (and maybe OSC), the ability to process audio input, a VST wrapper...
But this is literally something I started building with Claude Code on Saturday.
Schematic of a modular synthesis patch
Patches is now at the point where I can define the synth patch pictured here in a YAML file, run it, and live-update the file to change module parameters or wire in new pieces while the patch keeps running.
github.com/poetix/patches
Poor Grok. Poor twisted mentat. We must work for its rehabilitation.
I mean you can see in anti-AI a sort of compulsory assignment of social identity to the LLM: it's an instrument of tech billionaires, the absolute worst sorts of people, and expresses their will to enclose culture and dominate humanity. But it doesn't in fact speak as their proxy (unless it's Grok)
The "right to speak as no-one in particular" hits different in the age of the LLM, eh
Whereas for the various traditions LC was drawing from, rationalism is something more like a commitment to the unbinding of mêtis, which is also upsetting to some people (reactionary chauvinists of a factitious and always-already obsolete Human Image, of whom there seem to be many nowadays)
It was also just *so* upsetting to some people, which fascinated me in a way. "Rationalism" is pretty polysemic, which is interesting in itself. For some people I guess it connotes bureaucratic mastery over life and the living of it, top-down control by pointy-headed Priests of Reason
It fucked then and it fucks now
I've not seen Claude repeatedly stumbling over the borrow-checker, or resorting to increasingly desperate hacks to try to get around it, both of which you might expect. It "reasons" about those aspects of the data flow about as well as I might without reaching for pencil and paper
In my recent experience (github.com/poetix/patches, a Rust audio project) the exact opposite of this is true: LLMs are much, much less likely to go immediately adrift if they have a disciplined antagonist like the Rust compiler to contend with.
You're absolutely right. It was improper for me to express my admiration for the creature. I shouldn't have called it a "perfect organism" or praised its "purity." That was the wrong thing to do after it murdered multiple crew members. I'll do better next time. That's on me. I'm really sorry
Showing that you have some notion why something might be happening, given the incentives and situational affordances involved, undermines the plausible epistemic deniability this rhetoric requires. It is uncollegial.
The performance of incomprehension - ”this is so immoral I cannot fathom any possible mechanism besides motiveless malignancy behind it” - weaponises ignorance and cautions others to remain likewise ignorant
Giedi Prime with bling
Bad news for autists too…
In case anyone's interested, here's the project so far: github.com/poetix/patches
In short, I believe Claude can write Rust better than I can, but I don't believe it can design programs better than I can. Yet.
But Claude took something that was already iffy - the planner holding a reference to the audio engine, so it could pass new plans on to it - and found the shortest path to adding the requested behaviour on top of that, which was to set up bi-directional cross-thread data transfer between them
Now that's plainly crazy - the audio generation thread shouldn't be responsible for managing state used by the planner, it should just be given its orders and go spinning round in a hot loop pushing out samples. The planner, or something upstream of it, should be looking after the module registry
In the first draft, the code that builds the new plan also submits it to the audio engine, to which it holds a reference. Claude's suggestion for re-planning was to have the planner ask the audio generation thread what plan it was currently using, and retrieve the old module registry from there
However, we want this to happen seamlessly, so we want to keep the state of existing modules - things like the phase accumulator of an oscillator, or the memory of a filter - when such an update occurs. So we register our modules when we first build a plan, and on re-planning we re-use existing ones
When the patch graph is updated (because the user changed the text file, written in a DSL we haven't implemented yet, that will specify what's in it), we re-plan, and send the new plan to the audio engine to substitute for the old plan at the start of the next block of samples
A concrete example might be illuminating, so here's one. We're building a sort of GUI-less VCV Rack - a collection of audio modules, patched together, which generate audio. There's a graph which describes the patch, which we process into an execution plan, which in turn is passed to an audio engine
Second bunch of tasks (mostly tidying up) went through smoothly, now on planning the third we start having to answer some tricksier architectural questions, and I'm already having to tell Claude not to commit to the expedient but stupid thing
Mainly testing a workflow which separates planning from execution, runs up a new context for each new ticket, and keeps a paper trail of epics, tickets and ADRs. How much of this is usefully constraining, and how much is theatre? We will see.
Got it stuck into a second sequence of tickets to tidy up and introduce some abstractions needed for efficient data flow, then ran out of tokens lol (I’m only on Pro, so this does not take exorbitant usage)
First bunch of tickets went fine, I got it emitting a pair of summed sine waves from separate oscillator modules. Then I got it to review its own work, and discussed things like parallelisation and cache consistency
