• 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 around 15 or 16 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 over the past few months 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 nothing is currently 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; nothing is running, so nothing needs you unless you decide to start something.

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, in any order.

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) the year after, 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 and curl (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.

The standard top-to-bottom layout works well for phrase structure trees in generative grammar, where the depth is moderate and the width grows with sentence length. But for classification hierarchies, taxonomies, and certain dependency structures, horizontal trees are a more natural fit. They read like an outline and make better use of screen space when the tree is deep but narrow.

Here is the same sentence tree rendered in both directions. The input is bracket notation:

[S [NP [D the] [N cat]] [VP [V sat] [PP [P on] [NP [D the] [N mat]]]]]

First, the conventional top-to-bottom:

And the same structure laid out left-to-right with -d ltr:

The feature is available from the command line with the -d ltr flag, and via the web interface.

Where horizontal layout really shines is in classification trees. A taxonomy like the one below becomes unwieldy when drawn top-to-bottom, but reads cleanly from left to right. The -p on flag draws polyline connectors instead of the default diagonal lines, which suits classification diagrams better:

Internally, the tree is always computed top-to-bottom, then coordinates are transformed at the rendering stage. The same approach could support other directions. Right-to-left might be useful for visualizing structures in Arabic or Hebrew. Bottom-to-top, while rare in theoretical linguistics, could work well for phylogenetic trees in linguistics or biology. Neither is implemented yet, but both are worth considering.

Install or update: gem install rsyntaxtree

• RSyntaxTree web app
• RSyntaxTree example gallery
• RSyntaxTree documentation

The workflow

%%{ init: { "flowchart": { "curve": "linear" } } }%%
flowchart LR
    subgraph Local
        write["Write Markdown"] -- build.rb --> preview["Preview"]
        preview -. fswatch .-> write
    end

    subgraph GitHub
        repo[("Repository")]
    end

    subgraph Server["yohasebe.com"]
        pull["git pull"] --> build["build.rb"] --> nginx["nginx"]
    end

    write -- "git push" --> repo
    repo -- "webhook" --> pull

I write posts in Markdown with YAML front matter. Running build.rb serve starts a local preview server and watches for file changes via fswatch, rebuilding automatically whenever I save.

When I push to GitHub, a webhook notifies my server, which pulls the latest changes, runs the build script, and the updated site is served by nginx. The whole process takes a few seconds.

Tech stack

• Markdown processing: kramdown with GitHub Flavored Markdown, Rouge for syntax highlighting, KaTeX for math, and Mermaid for diagrams (pre-rendered to SVG at build time)
• Image handling: Automatic EXIF metadata stripping and responsive sizing based on intrinsic dimensions
• Search: Client-side full-text search using an inverted index generated at build time

The source code is in a public GitHub repository. As I wrote in an earlier post, plain text files under Git are the most durable publishing format I know of.

What if one of those slots expects a named entity – a person, a place, a historical event? Traditional corpus tools can find word patterns, but they have no way to ask for "a country name" or "a famous person".

TCSE (TED Corpus Search Engine) recently added support for %ENTITY notation in its advanced search, which treats named entity types as typed variables. %PERSON matches any person name, %GPE matches any country or city, %ORG matches any organization. See the documentation for the full list of supported types. Under the hood, the feature uses spaCy's NER annotations, which are stored for every token in the corpus of 6,400+ TED Talks.

This turns out to be useful for finding constructions that would be hard to locate with plain keyword search. Let me show a few examples.

X since %EVENT

Named events – wars, depressions, revolutions – serve as fixed points on a historical timeline that speakers use to anchor claims about the present. The construction pairs since with a named event and treats the event as a temporal benchmark.

• the worst humanitarian crisis since World War II [source]
• the greatest transformation since the Industrial Revolution [source]
• the greatest debt crisis since the Great Depression [source]
• the first human to cross the channel by land since the Ice Age [source]

The interesting thing here is what %EVENT lets us filter out. A search for since alone returns an enormous set of hits – "since 1973", "since last year", "since we started" – most of which anchor to a date, a time, or a clause rather than to a named occurrence. Swapping in %EVENT isolates a genuine subcategory: the construction where the benchmark is a named happening of any scale that the audience is expected to recognize. That is a distinction you cannot draw with keywords or part-of-speech tags.

the %PERSONs

English uses the plural form of a proper noun in several ways. "The Smiths" can mean a specific family. The construction I want to highlight here is different: the name is pluralized not to pick out a family but to stand for a type – "people like X".

• they might become the Darwins of the 21st century, studying urban evolution [source]
• It is the Shackletons of our offices rather than the Amundsens, who serve as role models, who get promoted and who get rewarded. [source]
• Her name was Dottie and he made a vow that day to always know the Dotties in his life. [source]
• helping the Sams of the world [source]

What typically marks this usage is a restricting phrase like of the world, of the 21st century, of our offices, or in his life, which anchors the name to a type rather than a household. In the Darwin, Shackleton, and Amundsen examples, the names are famous ones and the construction invokes the category they stand for – urban ecologists inheriting a scientific tradition, or the reckless explorer versus the methodical one as office archetypes. The Dottie and Sam examples are different: Dottie is a specific person the speaker's friend had noticed in passing, and Sam is the speaker's own name, used to refer generically to people in situations like hers. In neither case does the audience need to identify the individual behind the name. The construction itself signals "read this as a type, not an individual".

meanwhile in %GPE

Place names participate in constructions too. meanwhile in %GPE¹ is a discourse marker that introduces a parallel scene – "while that was happening here, over in X something else was going on". It is a narrative device speakers use to cut between settings.

• Meanwhile, in New York City, the NYPD has driven police cars equipped with license plate readers past mosques. [source]
• Meanwhile in Constantinople, Anna fought her own battle. [source]
• Meanwhile, in Australia, you can find a second type of mammal – marsupials. [source]
• Meanwhile, in Copenhagen we're actually expanding the bicycle lanes. [source]

One more advantage of NER search is worth pointing out here: multi-token entities are treated as single units. Among the examples above, Copenhagen and Constantinople are single tokens, while New York City is three. spaCy's NER marks all of them as a single GPE, so %GPE matches the whole span in each case. A search for meanwhile in %GPE does not need to worry about how many words the place name has. That kind of chunking is essential when the slot has to accept anything a speaker might name.

Why this matters

None of the constructions above is exotic. Linguists have studied many patterns like them. What is new is the ability to find them systematically across a curated corpus without knowing the filler words in advance.

For a construction grammarian, the ability to specify a slot as "any person name", "any place name", or "any named event" matches the way we think about constructions in the first place – as schemas with typed variables, not as lists of word combinations. NER search lets the search interface catch up to the theory.

The cost of writing in a foreign language

Until recently, writing in English meant spending far more time than writing in Japanese – drafting, checking grammar, looking up expressions. LLMs have compressed that gap dramatically. I can now draft, revise, and polish English text with an efficiency that was simply not possible a few years ago. The effort gap between writing in my mother tongue and writing in English has become small enough that it no longer feels like a decisive factor.

Writing in a language that is not yours

Japanese requires a lot of decisions before you even get to the content. Formal or informal register (desu/masu or plain form)? Which first-person pronoun (watashi, boku, ore, or something else)? Every language has such choices, but the difference is that in your native language, you feel the full weight of them.

English has its own subtleties, of course. But as a non-native speaker, I am largely exempt from them – or at least unaware of them. That turns out to be liberating. I am not trying to write poetry here. I want to describe facts, share observations, and record what I think. Having fewer choices – or more precisely, being unable to see most of them – makes that easier.

Reaching whoever finds it interesting

I am not writing for a specific audience. If anything, I would like these posts to be found by anyone, from any country or cultural background, who happens to care about the same topics. For better or worse, English has established itself as a global lingua franca, and it is the most practical choice for this kind of open-ended reach.

Not wanting to get tired of social media

I also want this blog to serve as a kind of personal log – things I have been working on, things I have been thinking about, things I have enjoyed. Social media platforms are designed to let you do exactly that, but they come with a cost: the moment you consider posting something, you start thinking about the reactions. Likes, replies, retweets. That feedback loop subtly reshapes what you write, and sometimes stops you from writing at all. A personal blog with no comment section and no analytics does not have that problem.

Owning the medium

Everything published on the open web will almost certainly be ingested by AI training pipelines. That is just the reality now. If I am going to put things out there, I want to do it on a medium I control as much as possible. This site is built from plain Markdown files stored in a GitHub repository, rendered into static HTML by a small Ruby script, and served from my own server. The content is mine, the edit history is mine, and the format is as durable as anything I know of. Text files in a Git repository will outlast any blogging platform.

What is collocation?

A collocation is a pair of words that co-occur more often than chance would predict. "Make a decision" sounds natural while "do a decision" does not – collocation is the concept that lets us quantify this kind of bond between words.

Statistical measures

TCSE uses three statistical measures to assess collocation strength. The formulas below use the notation of a 2x2 contingency table:

$O_{11}$ is the observed co-occurrence frequency of the two words, $R_1$ and $C_1$ are the individual frequencies of each word, and $N$ is the total number of tokens in the corpus.

Mutual Information (MI)

MI expresses, on a logarithmic scale, how much the observed co-occurrence exceeds what we would expect under independence. Higher values indicate stronger association.

A known weakness of MI is that it tends to overestimate the strength of low-frequency pairs. To compensate, we use t-score alongside it.

t-score

where $E_{11} = \frac{R_1 \cdot C_1}{N}$ is the expected frequency under independence. t-score is better suited for detecting high-frequency, stable collocations.

Difference of Proportions (DP)

This takes the difference between the rate at which the collocate appears in the context of the target word and its rate elsewhere. It is intuitive to interpret and can be read as an effect size.

Visualization: the network for "beautiful"

Below is the collocation network generated by searching for "beautiful" in TCSE (filtered at MI >= 3, 50 nodes).

Node color represents part of speech: nouns (blue), verbs (red), adjectives (green), adverbs (orange). Node size is proportional to co-occurrence frequency.

Several interesting patterns emerge.

The adverb cluster (stunningly, incredibly, remarkably, exquisitely) consists of intensifiers that amplify "beautiful", reflecting the subjective evaluative function of the adjective.

The noun cluster splits in two directions. Concrete objects (garden, landscape, beach, picture, architecture) and abstract concepts (symphony, pattern, diversity) are positioned separately, showing that "beautiful" spans both sensory and abstract notions of beauty.

The large node for "thing" is also notable. "Beautiful thing" is a frequent expression in TED Talks – a discourse pattern where speakers refer to something as "a beautiful thing" without naming what exactly is beautiful.