Here is They swim, the sentence Sag, Wasow and Bender (2003: ch. 3) use for the first worked example of their feature-structure grammar, drawn with the detail cut down to what the picture needs:

[#*phrase*\
  HEAD\t|1|\
  SPR\t〈<>〉
  [#|2|<>*word*\
    HEAD\t#(*noun*\
    AGR\t|3|<>#(PER\t*3rd*\
    NUM\t*pl*#)#)
    they
  ]
  [#*word*\
    HEAD\t|1|<>#(*verb*\
    AGR\t|3|#)\
    SPR\t〈<>|2|<>〉
    swim
  ]
]

Each node is a matrix: a type in italics, then attributes and their values. A value can itself be a matrix. The HEAD of they is a noun object carrying an agreement matrix inside it. The boxed numerals mark structure sharing, two places in the description holding one value. Tag 1 says the HEAD of the phrase is the HEAD of the verb. Tag 2 says the item the verb's SPR (specifier) list asks for is the subject word itself. Tag 3 says the noun's agreement features and the verb's are the same thing.

A label can also be nothing but a matrix, with no tree around it. This is the f-structure of David handed Chris a toy, after Bresnan (2001):

[#PRED\t‘hand⟨SUBJ,<>OBJ,<>OBJ_θ_⟩’\
  TENSE\t*past*\
  SUBJ\t#(PRED\t‘David’#)\
  OBJ\t#(PRED\t‘Chris’#)\
  OBJ_θ_\t#(SPEC\t*a*\
  PRED\t‘toy’#)
]

Diagrams of this kind are usually prepared in LaTeX with packages like avm or langsci-avm. RSyntaxTree draws them from the same short bracket notation it uses for trees, in the browser, with SVG, PNG and PDF output. The notation is described in the documentation, and the example gallery has figures for HPSG and LFG, each listing the input and settings it was drawn from.

Bresnan, Joan. 2001. Lexical-Functional Syntax. Oxford: Blackwell.

Sag, Ivan A., Thomas Wasow, and Emily M. Bender. 2003. Syntactic Theory: A Formal Introduction. 2nd ed. Stanford: CSLI Publications.

Until now, every subtree was given a horizontal slot wide enough that it could never meet its neighbours. That is simple and always works, but much of the reserved space goes unused. Each embedded phrase pushes its siblings apart, and trees nest deeply, so even a small structure can come out wider than it needs to be. Here is one from Chomsky (1995: 50), drawn the old way:

tidy off — 969 px

Tidy layout measures the actual shape of each subtree and slides neighbours together until they almost touch. There are three levels of packing, drawn here at the same scale as the tree above:

tidy low — 772 px

tidy medium — 597 px

tidy high — 565 px

The levels differ in how far a subtree may slide under its neighbours. low never lets two words overlap horizontally, so no word ends up directly above or below another. medium allows it, and that is what narrows the tree: above, John and cause have ended up one above the other. Neither may pass the other, so the words keep their left-to-right order. high keeps that order only within a row, and it gives up one more rule the lower levels hold to: that a pair of branches is never packed tighter than the pair below it. That rule is what keeps branch angles similar from one level to the next, and dropping it is what lets high go narrower still.

How much any of this helps depends on the tree. A balanced tree has little space to recover; a deep branch beside a shallow one has a lot. For this tree I would use medium. high takes another 5% off the width, but its angles are visibly less even, which is a poor trade at this size; it earns its place on trees that really are too wide to print.

The other main improvement in this release is multilingual rendering. Every font style now falls back to Noto Sans/Serif/Mono CJK, so Hangul and both simplified and traditional Han render in all of them, and Arabic, Hebrew, Devanagari, Thai and Khmer are named explicitly in the font chains. Machines that have those fonts installed now produce the same shapes from the same input. A new mirror option flips a finished tree horizontally, for the right-to-left convention used in Arabic and Hebrew. The example gallery has a multilingual section showing the same sentence in nine languages, and each example now lists the settings used, so it can be reproduced in the web interface.

Chomsky, Noam. 1995. The Minimalist Program. Cambridge, MA: MIT Press.

The main pane runs Claude Code on the project as usual. The split pane runs another agent: a coding agent from another vendor (Codex, Gemini, Grok, Kimi, and so on), or a second Claude Code. Either way, each agent gets a role. For example:

• Reviewer. Before committing to a design, have the model next door read it.
• Implementer. One agent writes the design and reviews the result; the other does the implementation.
• Editor. One agent writes a document, the other edits it, and the draft passes back and forth between them.

Sidekick support consists of two pieces.

The first is a way to tell ccm about the sidekick. ccm tracks one Claude Code session per project window, as before, and the second pane can now be declared a sidekick: the window's state continues to reflect the main session alone, while the sidekick shows up as present, deliberately left outside the tracking.

The second is a direct line between the two agents. How to deliver a message to the other side is decided in advance, so the agents can talk to each other without a human copying text between panes. A message to the main session never lands in a permission dialog; in the other direction, the sender first checks that the peer is ready. Neither side has to keep watching the other: when an agent finishes a request, it reports back, and the reply arrives as a normal conversational turn. The details are in the documentation.

None of this depends on the peer being a particular product. The conventions are plain tmux and plain text, so any CLI that can run a shell command – Codex CLI, Gemini CLI, Grok Build, Kimi Code, among others – can participate.

Agent-to-agent support is already being tried in many forms, and I expect it to matter more and more. First-party apps from each provider know their own models and APIs well and are highly capable, but they tend to be less eager about working with other providers' models. For the time being, this looks like a place where open-source tools can be of use.

The first is jReadability, which measures how difficult a Japanese text is to read. You paste in a passage and it returns a readability level, along with a breakdown of the features behind that score. The underlying measure was derived from levelled corpora – texts graded by difficulty – and the system has been in use since the early 2010s, mostly by teachers choosing or adapting materials for their students.

The second is jWriter, which evaluates writing by learners of Japanese. It estimates a learner's proficiency from a submitted essay, using a regression model built on I-JAS, a large corpus of learner writing. Alongside the level estimate, it reports diagnostic features: vocabulary diversity, the use of Sino-Japanese vocabulary, average sentence length, and a measure of logical structure. None of this involves a language model. It is corpus statistics, and it has worked in much the same way for years.

Recently we added LLM-based feedback to jWriter. There are four functions: written comments on the essay, sentence-level suggestions, a rewrite for comparison, and an evaluation of the learner's own revision – so the process does not end with a score, but continues through revising and being re-evaluated. The rewrite, by the way, is displayed but cannot be copied: it is there to learn from, not to hand in.

The part that matters in the design is that the language model does not work from the raw essay alone. The proficiency estimate and the diagnostic features computed by the older machinery are passed to it as part of the prompt. This is meant to keep the evaluation more consistent and grounded than leaving it to whatever a general chat model happens to produce on a given run. Corpus-based work from before generative AI may not simply be replaced by language models; its role may change instead, giving the models a footing and supporting finer-grained analysis.

I wrote earlier about a related study comparing how AI and human editors simplify text. The suggestion there was that AI and human language processing have different strengths and can complement each other. The same idea underlies these tools: not AI as a replacement for teachers, but as something that works alongside them.

Lee, J.-H. and Y. Hasebe. 2020. Quantitative Analysis of JFL Learners' Writing Abilities and the Development of a Computational System to Estimate Writing Proficiency. Learner Corpus Studies in Asia and the World 5, 105-120. PDF

Lee, J.-H. and Y. Hasebe. 2020. Readability Measurement of Japanese Texts Based on Levelled Corpora. In I. Srdanović and A. Bekeš (eds.), The Japanese Language from an Empirical Perspective: Corpus-Based Studies and Studies on Discourse. Ljubljana: Ljubljana University Press, 143-168. DOI

Hasebe, Y. and J.-H. Lee. 2015. Introducing a Readability Evaluation System for Japanese Language Education. Proceedings of the 6th International Conference on Computer Assisted Systems for Teaching & Learning Japanese (CASTEL/J). PDF

Hasebe, Y. and J.-H. Lee. 2025. Divergent strategies in text simplification: A comparative analysis of AI and human approaches in language processing. Intercultural Pragmatics 22(2), 203-230. DOI

• L'Arc~en~Ciel: READY STEADY GO
• Southern All Stars: MISS BRAND-NEW DAY
• Ricky Martin: Livin' La Vida Loca
• Yosui Inoue: Higashi e Nishi e
• Sakanaction: Shin Takarajima
• Suchmos: STAY TUNE
• 10-FEET: Dai Zero Kan
• THEE MICHELLE GUN ELEPHANT: Get Up Lucy

I had almost no part in the song selection. The members bring in what they want to play, and many of the songs are ones I would never pick up on my own. Working out how to arrange and practice them turns out to be the fun part.

I get notes from the other members, and not a few of them. Guitar tone, phrasing, how I ride the rhythm, sometimes even how I move on stage. Figuring out how to respond to each of these is enjoyable in itself, and I keep learning from it.

• Quantitative analysis (analyze_audio_features): a Python pipeline using librosa and madmom measures duration, tempo, key, time signature, chord progression, and sections. These are numbers, computed from the signal.
• Qualitative evaluation (critique_audio): the same audio goes to Gemini's audio-understanding endpoint for a critique: character and mood, genre, instrumentation, and performance qualities like expression, phrasing, dynamics, and timing.

The qualitative side rests on a documented capability: among the use cases Gemini's audio documentation lists is to "Detect emotion in speech and music." The recording I use to show it is my own playing, a rough solo from a cover session, included so the feature comes with audio you can actually hear. Please excuse the rough playing.

How it fits together

A chat model, the orchestration agent, receives the upload and, for a normal analysis, runs both tools. The two are different in kind: analyze_audio_features is a deterministic Python step, not a language model, while critique_audio is a separate Gemini call that receives only the audio. It does not see the measured numbers, so its impressions come from the sound rather than from the quantitative output. Both results return to the orchestration agent, which assembles the reply.

The qualitative prompt is kept within what the model can actually support: it does not judge audio fidelity, mix, or stereo image (per the same documentation, Gemini folds multi-channel audio down to a single channel and downsamples it), it leaves exact tempo and key to the quantitative tool, and it names only instruments it can hear, treating genre as a tentative guess rather than a firm label.

Trying it on a recording

I ran it with almost no context attached. No song title, no artist, no genre:

Please analyze solo-sample.mp3. It is a short electric-guitar solo I recorded in a session with friends. Run both of your analyses on it: first the quantitative, measured features (tempo, key, time signature, chord progression), then a qualitative evaluation of the performance, focusing on the lead guitar's expression, phrasing, and timing/groove. Please identify the genre/style and instrumentation you hear as part of the evaluation, and present the quantitative features and the qualitative evaluation as clearly separated sections.

The recording:

Quantitative features

• Duration: 0:36
• Tempo: 73.8 BPM
• Key: E minor
• Time signature: 4/4
• Chord progression: centered on E minor (Em, C, G, Am, with a passing D# and A)

The tempo and key match the recording. Because this is signal processing rather than judgement, the numbers are basically the same on every run.

Qualitative evaluation

This is Gemini's qualitative evaluation, formed from the audio. Here are excerpts from the report:

Genre, style, and instrumentation

The critique hears the track leaning strongly toward a high-energy style of hard rock, perhaps drawing heavily from late-1960s or 70s psychedelic rock, blues-rock, or early heavy metal. The instrumentation appears to be a classic power-trio lineup: an overdriven, highly sustaining electric lead guitar as the primary voice; a driving bass guitar providing low-end propulsion; a steady, fast-paced drum kit keeping a relentless, straight-ahead rock beat.

Expression

The guitarist's expressive vocabulary is highly physical and deeply vocal. The critique notes a rich use of wide, aggressive vibrato, dramatic pitch bends, and slides that give the guitar a singing, almost human quality. The sharp, dig-in pick attack drives the amplifier into a rich saturation, creating a raw, tactile connection that makes every note feel urgent and deeply felt.

Phrasing

The phrasing operates on a tension-and-release dynamic using familiar blues-scale and pentatonic frameworks. The performance contrasts long, soaring sustained notes with rapid, explosive flurries of ornamentation. It has a spontaneous, improvisational feel, though the critique notes that the phrasing sometimes leans heavily on continuous, busy activity, leaving little room for silence or breath.

Timing and groove

Set against a driving rhythm section, the lead guitar rides on top of the beat with a highly pushy, forward-leaning attitude. While this adds frantic, exciting energy, it also presents a challenge: during the faster, subdivided runs, the guitarist has a tendency to rush, momentarily crowding the pocket and pulling slightly ahead of the drummer's steady groove.

How far to trust it

That the quantitative analysis is deterministic does not make it correct: it returns the same values for the same input, but it can still mis-read; chord detection in particular sometimes mistakes the harmony. The qualitative evaluation is shakier: it runs only on Gemini for now, and depending on how the prompt is built it can name an instrument that is not in the recording. In earlier iterations, before I added those constraints to the prompt, the qualitative tool sometimes mentioned a rhythm guitar that was not actually on the track. The performance may not be quite sufficient yet. Still, as better models arrive, having AI evaluate recorded music like this should become a realistic and genuinely useful practice.

On policy, Anthropic say they would support a coordinated international pause under certain conditions, specifically if verification systems existed so frontier developers could confirm others had actually stopped. A unilateral pause by one lab, they argue, would mainly just change who the front-runner is.

I work on Monadic Chat, a locally hosted AI chat platform. I have kept it multi-provider deliberately. Today it routes to seven hosted providers and one local runtime:

• OpenAI (US)
• Google (US)
• xAI (US)
• Anthropic (US)
• Cohere (Canada)
• Mistral (France)
• DeepSeek (China)
• Ollama (local, not tied to any jurisdiction)

The reason is less a principle than a practical hedge. Without an international coordination framework in place, regulation, if and when it comes, is likely to take different shapes across providers, jurisdictions, and timelines. If a user has only one route to the AI work they want to do, their work can stall when those rules change first. More routes mean more flexibility as things change.

At the same time, what Anthropic are calling for seems reasonable to me. Paying attention to the trajectory and setting up structures that would let humans intervene later is hardly an overreaction.

Over the last few years I have been watching the layers AI handles in development grow. Snippet suggestions, then function coding, then codebase design, technology choice, execution, testing, debugging. I built ccm for tmux on the working belief that the last thing left on the human side is attention and judgment. The Anthropic piece argues that even that layer is starting to move.

There is not much an individual developer can do at this scale. Most of what I build either reinvents something that already exists or gets superseded by a larger project. I keep building anyway. Honestly, the AI built on top of large language models is becoming a more and more complete black box for ordinary users. Before it fully gets there, I want to grasp what is happening, as far as I can, for myself. I cannot enter the model development race. But building my own tools is itself a way of keeping some control on my side, however small. At least I can see what is happening firsthand.

That was a few years ago. Gmail has been winding down its "Check mail from other accounts" feature and signaled that further changes are coming. Microsoft has tightened authentication, and the old way of pulling Outlook addresses into Gmail no longer works. Each provider has retreated into its own walled garden.

For someone with email spread across several services, there are few good options now. Cloud-side aggregators have mostly vanished, and local clients come with their own trade-offs, most notably being tied to a specific device.

Back in 2022 I worked through this and moved to Fastmail. It is paid, but it handles the multi-address case cleanly. It is independent of the big platforms, lets you host your own domain, and sticks to open standards. I also built a small Chrome extension on the side, Fastmail Plus, to smooth over a few UI quirks of my own. It had sat untouched for a long stretch. I brought it up to date with the current UI this week.

Authentication standards have been tightening across the industry, and POP-based bridges are being phased out. Email itself is not going anywhere, but the way to handle several addresses now is to pick a single host and live there.

One format I have been running lately, with groups of 15 to 20 students, is short one-minute English talks on a given theme. "A foreign city I would like to visit." "The greatest invention or discovery in human history." Themes broad enough that each student can choose something personal, specific enough that they have something to say.

Some kind of visual aid usually makes these sessions more engaging. But the talks happen one at a time, students pick their own topics, and I do not know what all of them are until they speak. There is no preparing a slide deck in advance.

Monadic Chat's Image Generator, backed by OpenAI's gpt-image-2, solves this. A prompt like:

Create a matrix-style image of the following N items, with numbered labels.

together with the list of student topics produces a single grid image on the spot, which I project on the classroom screen as the talks proceed.

Theme: "The greatest invention or discovery in human history."

Theme: "A foreign city I would like to visit."

ChatGPT or Gemini can do this just as well, and plenty of teachers already work this way. The shape of classroom teaching is certainly shifting.

The latest Monadic Chat, an AI chat platform I work on, moves this end to end onto your machine.

The earlier setup used OpenAI's text-embedding-3-large for the help system and PDF knowledge base, with PGVector for storage. It worked for static documents, but extending the same path to conversations would have meant every chat passing through a cloud embedding endpoint just to be findable later. I wanted to avoid that. The new embedding pipeline is fully local:

• An embeddings container running multilingual-e5-base (sentence-transformers)
• A Qdrant container holding the vectors
• A two-level embedding scheme: a summary per conversation, plus the individual turns inside it

Qdrant is an open-source database designed for embeddings: it stores them and searches by similarity in meaning rather than exact wording.

The same store also holds PDF and document content if you've imported any, so search works uniformly across whatever you've put into the knowledge base.

Search is cascade: a query first hits conversation summaries, then drills into the matching conversations turn by turn. The retrieval is wired up as a RAG tool too, so past content can be pulled into the current chat as context when the model decides it's useful.

And if you pick an Ollama-backed model for the chat itself, it runs locally too.

The latest Monadic Chat, an AI chat platform I work on, does this for you, invisibly. You type the original. Before send, a local detector replaces PII (personally identifiable information) with typed placeholders. The LLM gets <<PERSON_1>>; you keep seeing the real name on screen. When the response comes back, any placeholders it preserved are restored to the original values for display.

The detector runs in its own Docker container with Microsoft Presidio + spaCy. Presidio handles pattern-based categories (email, phone, credit card, SSN, IP, URL, and others); a local spaCy NER model handles context-dependent ones (people, organizations). Detection is multilingual, supporting 9 languages.

A few properties that matter:

• Per-session: each chat gets its own placeholder registry, in memory. Nothing accumulates as a growing on-disk record of who you've talked about. If you export an encrypted session and import it again later, the registry is restored alongside the conversation, so masking keeps working on follow-up turns.
• Per-app: the toggle shows up only on apps where masking makes sense (Chat Plus, Mail Composer, Translate, Second Opinion). Apps focused on code generation or media output don't expose it, since their inputs rarely carry personal information.
• Fail-closed: in the unlikely event the privacy container can't run, the main chat still works, but background calls that would send extra text to the cloud (title suggestion, second opinion) are skipped rather than sent without masking.
• Detection is probabilistic: pattern-based categories (emails, phones, etc.) are caught reliably, but the NER paths for names and organizations will sometimes miss novel forms or edge cases. The filter substantially reduces what leaves the machine; it doesn't guarantee zero leakage.

The LLM only sees the type label (<<PERSON_1>>, <<EMAIL_1>>), not the actual value. It knows what kind of thing is hidden, but not which specific one. For rewriting, summarizing, translating, drafting, that level of knowledge is enough. For tasks where the specific value matters, you can just turn the filter off for that session.

I have been building ccm for tmux as an answer to this. It does several things now, but the pieces that defined the project from the start trace back to a single question: which window should I be looking at right now?

The mental model

ccm assigns each project to its own tmux window. The window can hold Claude Code alongside a shell, a dev server, or any other long-running process. The state of the Claude Code pane (PERMIT, BUSY, IDLE) propagates up to the window itself, and ccm lets you move between windows with prefix + Tab.

States that map to urgency

Each Claude Code session moves through phases. It is reasoning or producing output (BUSY). It pauses to ask permission before taking some action (PERMIT). It finishes and waits for the next prompt (IDLE). Or no Claude Code session is running in the window (SHELL). ccm reads each tmux pane's contents in the background and tags the window with one of these states.

The four states sort cleanly by urgency:

PERMIT > BUSY > IDLE > SHELL

PERMIT is the most demanding: a session has presented options and is waiting for you. Miss it and the session sits frozen. BUSY is next – a session is producing output that you may want to follow or course-correct. IDLE is comfortable: the session has done what was asked, and there is no pressure. SHELL is the lowest priority; no session is running, so nothing needs you unless you decide to start one.

ccm also moves windows to SHELL on its own. A session that has been idle for a while is auto-exited to free memory and CPU, then restarted with --continue (resuming the previous context) when you switch back. The state ordering is what the dashboard surfaces:

PERMIT rows land at the top regardless of original window order; the eye moves down from there. Switching to a project becomes a single keystroke once the decision is made.

Coordination across projects

A second feature applies the same state model across projects. ccm send <project> <message> queues a prompt into another project's session, with safety gating based on the target's current state. PERMIT-state windows are refused unconditionally – typing into a permission dialog could accidentally approve or reject a tool call. BUSY-state targets need explicit --force (the input is queued rather than mixed mid-turn). SHELL-state windows can auto-start Claude Code first.

This turns inter-project coordination into something close to message passing. The session in project A can – through me, as the human in the loop – ask the session in project B about its current state, share findings, request follow-up work. The same states that organize my attention also gate what flows between projects.

With Agent Teams

Once ccm send makes inter-project coordination routine, a natural next question follows: could the coordination itself be delegated to AI? Within a single project, Claude Code already does this through Agent Teams, where one session coordinates teammates running in parallel panes within a single window (tmux or iTerm2).

Because the two structures (panes within a window, windows across a session) do not overlap, they compose naturally. A ccm-managed window can host an Agent Team, and ccm aggregates state across the team's panes using the same priority order. If any teammate is at PERMIT, the whole window appears as PERMIT in the dashboard – so a single agent waiting for permission surfaces immediately even when focus is on a different teammate, and the human-side question stays the same: which window should I be looking at right now?

Attention as the human-AI interface

The opening observation – attention, not compute, is the bottleneck – seems to sharpen as more work moves to agents. Attention may be one of the places where humans and AI still meet, with the human role on that surface narrowing toward what to bring forward, what to ignore, when to interrupt. ccm is a small piece of that surface, and the rest is something I want to keep thinking about.

The most common aid is captions. Watch a video with subtitles and you can follow along. But captions can undermine the very thing we are trying to practice. Visual information tends to take priority over audio in our cognitive processing, and when the two arrive together, the work of extracting meaning from sound alone is reduced. Since captions are timed to the audio – or slightly ahead – the listener ends up reading rather than listening.

To address part of this, TCSE has long had a fullscreen mode (described in an earlier post) where no transcript shows during playback; only the previous and current lines appear the moment you pause. The listener has to attempt interpretation first, and only then check. But the answer-checking happens at sentence boundaries. You hear a whole sentence, decide what you think it said, then pause to verify. The granularity is coarse.

SpeechDock is a Mac app I have been building for speech-to-text and text-to-speech tasks. Unlike most STT apps, it can take its input from the microphone, the system audio mix, or the audio from a specific application. One of its modes runs that input through real-time STT (either macOS-native or a cloud provider) and displays the result as a HUD overlay on top of whatever is on screen.

SpeechDock real-time transcription overlaid on NASA's Ask NASA: How Will Astronauts Dig on the Moon? (00:16–00:46, public domain). The demo uses macOS's native STT, with VLC's audio output specified as the SpeechDock input source.

Real-time STT cannot show text at the same moment as the audio. There is always some lag in our verbal communication, for that matter: speech has to be heard, segmented, recognized, and interpreted. And there is always the possibility of revision when later input changes the parse.

Real-time STT makes this incremental, revisable parsing visible. The HUD is not a transcript that hands you the answer; it shows a process that mirrors the cognition you are trying to develop, unfolding before your eyes.

Whether this kind of tool actually helps L2 learners improve their listening is an open empirical question. If anyone wants to design a proper study together, please get in touch.

I only notice this when I am finding things. When I am putting them away, I am happy to take my time, placing each file somewhere sensible. Filing and finding feel like different kinds of work.

Filing can wait, finding cannot

Filing can wait. I have a moment to decide which project, which year, which subfolder. Getting it slightly wrong is fine – I can move the file later.

Finding cannot wait. By the time I notice I want a file, I want it now. Whatever fragments come to mind should be enough.

There are two common ways to organize files in the face of this. Neither works for me.

The first abandons hierarchy: keep everything in one flat space, tag each file, and search by tag. Retrieval is great. But filing becomes a chore. There is no obvious "right place" for a new file, and tagging well takes more discipline than I have. So I file less.

The second commits to hierarchy in both directions: organize as a tree, find by descending the tree. macOS Finder columns invite this. But finding becomes expensive. I have to know the tree to use it, and the fragments that come to mind first are not always at the top. I open the wrong folder, back out, try again – searching by walking, the slow way.

What both share is the assumption that storage and retrieval should mirror each other. But filing and finding are not the same activity, and forcing them into the same shape makes both worse.

A way that respects both

What I want is to keep the hierarchy I already have, and search across it with whatever fragments come to mind, in any order.

On macOS, the tool that does this for me is fzf-alfred-workflow, a small Alfred workflow I wrote some years ago. It plugs fzf and fd together so any space-separated fragments I type are matched against every path under my home directory (minus default exclusions such as ~/Library and node_modules), in any order.

The match runs over the whole path, not just the filename. The folders a file sits in are part of what I can search, so the route I chose when filing – project, year, topic – becomes material for finding later. And fragments typed through a Japanese IME now match filenames whether macOS stored them in composed or decomposed Unicode.

The pleasure of using it is less about speed than about a small relief: I no longer have to remember where things are. Filing stays hierarchical, because there is no rush when I file. Finding takes whatever fragments are in my head.

The same asymmetry shows up in language. Lexical concepts are organized hierarchically – an efficient data structure for organizing the world. But real-time lexical use does not behave like a tree search; it unfolds on a reference-point network, jumping from one anchor to another. The tool feels right because it stops trying to make filing and finding match. They were never going to.

In Monadic Chat's Voice Chat apps, this effectively lets the assistant act as an AI agent that also directs its own delivery – deciding where to laugh, where to whisper, and what overall color the voice should have, all at reply-generation time.

flowchart LR
    user["`🎤 **User audio**`"]:::io --> stt["`✍️ **Speech-to-Text**
(API call)`"]:::api
    stt --> llm["`🤖 **Chat model**
(single API call)`"]:::model
    llm --> text["`💬 **Reply text**`"]:::data
    llm --> cues["`🎭 **Delivery cues**
(tags or instructions)`"]:::data
    text --> tts["`🗣️ **Text-to-Speech**
(API call)`"]:::api
    cues --> tts
    tts --> out["`🔊 **Assistant audio**`"]:::io

    classDef io fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    classDef api fill:#ccfbf1,stroke:#0d9488,color:#134e4a
    classDef model fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef data fill:#ede9fe,stroke:#7c3aed,color:#4c1d95

Monadic Chat currently supports four TTS providers for this, and their APIs fall into two broad approaches.

Inline markers

xAI Grok, ElevenLabs v3, and Google Gemini all interpret tags embedded directly in the text. The engine consumes the bracketed tokens as stage directions instead of reading them aloud.

xAI Grok (model grok-tts, voice ara) is the only provider among the four that pairs point markers ([inhale], [sigh], [laugh]) with range markers – opening and closing tags that apply an effect to the enclosed span and then return to normal voice. The wrapping set includes <whisper>, <slow>, <loud>, <high>, and <sing> (xAI docs).

[inhale] <slow>Let me think about that for a second.</slow>
<whisper>Actually, between you and me, I already know the answer.</whisper>

ElevenLabs v3 (model eleven_v3, voice Rachel) uses single-token square brackets for everything. The vocabulary is emotional ([excited], [curious], [sad], [sarcastic]) and performative ([sings], [giggles], [sobs]) (ElevenLabs docs).

[excited] You won't believe this! [giggles] Oh my goodness.
[sings] La la la, la la la la!

Google Gemini (model gemini-2.5-flash-preview-tts, voice Zephyr) uses syntax similar to ElevenLabs v3, but with a distinctive vocabulary of situational moods: [mischievously], [panicked], [amazed], [trembling], [gasp], [shouting], [tired] (Gemini speech generation).

[amazed] Look at that cake!
[mischievously] I wonder if anyone would notice a missing slice.
[panicked] Quick, someone's coming!

Instructions

OpenAI's gpt-4o-mini-tts splits text and direction. The reply text stays clean, and a separate instructions parameter in the TTS API call specifies how to deliver the whole utterance. Because an instruction shapes the entire delivery rather than a moment, even a short text with a bit of emotional range is enough to hear the effect (openai.fm is a quick playground).

Because the instruction is free-form English, it is not tied to a fixed tag vocabulary. Voice quality, emotional arc, and pacing can all be described the way a director might sketch a scene.

OpenAI (model gpt-4o-mini-tts, voice ballad):

Input:
  "Oh my goodness, you are not going to believe this!
   You know that guitar piece I've been working on for months?
   I just played it all the way through -- no mistakes, clean as
   anything! I am so happy right now, you have no idea!"

Instructions:
  Voice: bright, giddy, absolutely bursting with joy.
  Tone: pure, uncontainable excitement from start to finish; each
        sentence should sound like it's barely holding the happiness in.
  Pacing: quick and breathless; strong emphasis on "no mistakes" and
          "so happy"; a triumphant beat on "clean as anything".
  Emotion: unfiltered delight and pride; the voice should practically
           glow.
  Delivery: a small laugh or giggle of disbelief should slip through
            after "all the way through"; the voice climbs in intensity
            toward the final line.

One thing worth noting: with OpenAI, the choice of voice makes a surprising difference to how instructions land. Neutral voices like alloy respond less dramatically, while coral and ballad pick up expressive directives much more readily. The sample above uses ballad.

Gemini also accepts natural-language direction placed at the front of the prompt, in addition to the tag-based approach seen earlier. Tags and directive can even be combined in a single prompt – the directive shapes the overall atmosphere while the tags pin down specific moments.

Google Gemini (model gemini-2.5-flash-preview-tts, voice Zephyr) in hybrid form (same utterance as the OpenAI sample above, delivered with a directive plus inline tags):

Input:
  "Say with this voice and style:
   Voice: bright, giddy, absolutely bursting with joy.
   Tone: pure, uncontainable excitement from start to finish.
   Pacing: quick and breathless; strong emphasis on 'no mistakes' and 'so happy'.
   Emotion: unfiltered delight and pride.

   Oh my goodness, you are not going to believe this! [giggles]
   You know that guitar piece I've been working on for months?
   I just played it all the way through -- no mistakes, clean as anything!
   [laughs] I am so happy right now, you have no idea!"

Fully model-native realtime voice APIs – OpenAI Realtime, Gemini Live, and similar – respond with lower latency and a more natural turn-taking rhythm, but they fold content, voice, and timing into a single model that the application cannot easily redirect. Monadic Chat's pipeline keeps the chat model and the TTS engine as separate stages, so any chat provider can be paired with any TTS provider, and the model – acting as an agent – can shape the content and its delivery in the same reply. The trade-off is immediacy for directorial control.

Normal and fullscreen viewing modes

When you play a talk in TCSE, the default view shows the video above a scrolling transcript, with translations side by side if a translation language is selected.

Normal viewing mode

Clicking the fullscreen icon at the bottom right of the player (or pressing ESC) switches into fullscreen mode. The transcript and translation disappear from the screen during playback. Press the spacebar to pause, and the text for the current segment appears in yellow and the previous segment in cyan, with the translation (if selected) below. Press space again to resume, and the text goes away.

Fullscreen viewing mode (paused)

A few shortcuts are useful during listening practice: R to repeat the current segment, A to toggle "Study Mode" (auto-pause at every segment boundary), and T to show or hide the translation. The full list is on the shortcut keys page; the feature itself is documented under "pause-and-check".

Why this mode exists

The design rests on a view of L2 listening practice I have held for a long time. If text is on screen the whole time, processing gets pulled toward the visual channel and the learner ends up hearing without really listening; but removing all text does not help either, since comprehension depends on context, and a learner who loses the thread early tends to spend the rest of the talk processing fragments. What is needed, and what pause-and-check tries to support, is spot access to the transcript – available when the thread breaks, not otherwise. The video plays without text in the way, and a tap of the spacebar brings just enough of the transcript back (the current and previous segments) to repair comprehension before resuming.

TCSE is, at its core, a search engine for language research and teaching, and this listening mode is not central to what it does. It is not the feature I would name first if asked what TCSE is for. But it is one of my personal favorites, and I hope language learners who land on a talk through search might find it useful once they have already found what they were looking for.

Current Monadic Chat architecture

A name from functional programming

In functional programming, a monad is a way of wrapping a value together with some surrounding context, such that you can keep operating on the value without having to manage the context by hand. The classic metaphor is "a value in a box": you put a into a box, you transform the contents of the box into b, and the box – whatever it contains – comes along for the ride.

When I was thinking about how to maintain conversational context across stateless API calls, this metaphor seemed to fit. Each user turn could be seen as a value, the conversation history as the surrounding context, and the act of producing a response as a transformation that happens inside that context rather than outside of it. The first version of Monadic Chat was a tiny Ruby program that did exactly this with JSON templates: each request carried an input, an output, and an accumulator, and the response itself became the next input. I wrote a short paper about it for the 2023 annual meeting of the Association for Natural Language Processing.

Discourse as monad

The reason the monad metaphor felt right was not only that it gave me a useful way to think about the software architecture. It also matched the way cognitive linguists describe what speakers and hearers actually do when they hold a conversation.

Ronald Langacker has written extensively about what he calls the current discourse space – a structured representation of the immediately relevant context that participants share at any moment in a conversation. Each utterance updates this space: new entities are introduced, previous ones recede, the focus shifts, and the updated space becomes the ground for the next utterance. The structure has some parallels with how a monadic computation passes its environment forward through each step.

The monad in functional programming is a precisely defined mathematical object, while the current discourse space is a theoretical construct in cognitive linguistics. I do not want to conflate the two, but the shape is similar enough that bringing them into conversation seemed worthwhile. I have explored the linguistic side of this elsewhere – in a talk at ICLC 16 in 2023 and in Ninchi Gengogaku Ronkou (Studies in Cognitive Linguistics) two years later, which I introduced on this blog earlier.

What matters, I think, is that how human speakers actually hold and manage context remains very much an open question in cognitive linguistics, and conversational AI may give us a new kind of object to think with – not only as a practical tool but as something that could feed back into theoretical work on discourse and cognition.

Where the project is going

Monadic Chat in 2026 is more eclectic than the original prototype. It speaks to multiple LLM providers, runs containerized tools, and handles images, audio, and video as well as text. It has grown into more of a multi-tool than a focused one. The project page has the current details.

Real discourse is typically multimodal: gesture, intonation, and the visible environment all tend to play a part in how people make meaning, even though formal linguistic theory has often lacked the tools to handle them and has tended to set them aside in analysis. Monadic Chat's handling of images, audio, and video is still only partial, but my hope is that it will become not only a chat tool that gradually grows into such material, but also a medium through which I can come to understand more concretely what context actually is, and what the current discourse space really looks like.

What it does

The script listens to the microphone, uses sox's silence detection to segment the audio into natural utterances, and transcribes each one. The key design constraint is that it is a single bash file with no dependencies beyond sox, curl, and jq (or whisper.cpp for local use). No Python, no Node, no virtual environment.

The v2.0.0 update adds:

• --stdout and --jsonl modes that skip all side effects (clipboard, file save, banners) and emit transcriptions directly to stdout. This makes the script pipe-native.
• Local backend via whisper.cpp — runs offline with no API cost, making always-on dictation practical.
• Speaker diarization through OpenAI's newer transcription models.

Why it matters as a building block

The --stdout and --jsonl modes are the important part. A speech-to-text tool that writes to stdout and nothing else can be composed with other programs. Because it is a regular Unix filter, you can build things on top of it without touching the source:

# send a desktop notification when someone says "urgent"
whisper-stream --stdout | grep --line-buffered -i "urgent" | while read -r line; do notify-send "$line"; done

# feed every utterance into an LLM
whisper-stream --jsonl | jq -r '.text' | your-llm-cli

A slightly more involved example: a wake-word assistant. The script listens continuously. When it hears a keyword, it plays a short beep to signal readiness, then sends the next utterance to an LLM.

whisper-stream --stdout | while read -r line; do
  if echo "$line" | grep -qi "hey computer"; then
    # next line from the pipe is the follow-up utterance
    read -r command
    echo "$command" | your-llm-cli
  fi
done

There is a brief pause between saying the wake word and seeing a response – a few seconds while the utterance is transcribed. But it runs on macOS and Linux alike, and I can see it working on a Raspberry Pi with a microphone.

TCSE now has an export feature, currently in beta. You can find the documentation here.

Page-by-page export

Each export returns the current page of search results – around 200 items, matching what you see on the screen. The interface already paginates results 200 per page, so "export what I am looking at" is the natural model.

I deliberately avoided a single-request bulk download of thousands of rows. Both server load and the appropriate use of a corpus built on publicly accessible transcripts argued against it, and keeping each export scoped to one page keeps each request as light as an ordinary page view.

If you need the full set of hits for a high-frequency query, you can simply page through and export each page in turn. A short five-second cooldown sits between exports as a simple throttle against accidental double-clicks and overly eager scripts, but it should not get in anyone's way in normal use.

What each row contains

On any search results page, a small "Export" button offers two formats:

• ZIP — a TSV file containing the rows, plus a metadata.json describing the query and the export
• JSON — everything in a single JSON file

Each row is not just the matched segment but the matched segment plus two segments of context before and after, along with the talk metadata (title, speaker, year, URL, duration). When you search with the Advanced Search syntax, the TSV also includes the part-of-speech, lemma, and dependency label of the matched token. When you have a translation language selected, the translation text is included too.

The TSV is UTF-8 with a byte-order mark, so Excel opens it without garbling non-ASCII characters.

Use cases

A few things this unlocks for TCSE users:

• Close reading of hits: download the hits for a word, construction, or discourse marker and work through them in a spreadsheet or a notebook, annotating by hand or running scripts
• Statistical work: load the TSV into R or Python, group by year or speaker, count co-occurrences, build visualizations
• Teaching material: build a small custom dataset for a class assignment without having to set up your own corpus pipeline

Beta status

The feature is live as a beta release. The core functionality is in place, but there may be rough edges to smooth out based on how people actually use it. If you try it out and run into anything odd, or if there is metadata you wish were included but is not, let me know.

In a language class, keeping everyone on the same sentence at the same time is surprisingly hard with existing slide tools. PowerPoint and Google Slides operate at the slide level. Moving focus from one sentence to the next within a single paragraph is not something they are designed to do well. Paradocs was built to solve exactly that.

It runs entirely in the browser with no server required, hosted as a static site. Text data stays in the browser unless you opt in to cloud-based speech synthesis.

Each press of a key advances the highlight to the next sentence. Here is what it looks like in presentation mode:

With v1.0.0, the following features are now in place, marking a milestone:

• Text-to-speech. Works for free using the browser's built-in speech synthesis, with optional support for OpenAI and ElevenLabs cloud voices. Word-level highlighting during playback.
• Fill-in-the-blank and multiple-choice quizzes.
• Multilingual UI: English, Japanese, Chinese, and Korean.
• Export as a standalone HTML file for offline use.
• Live preview with filmstrip thumbnails.
• Dark mode for both the editor and the presentation.

Paradocs was made for language education, but I imagine there are other situations where stepping through text one sentence at a time is useful. If you find such a use, I would be glad to hear about it.