DEV Community: Mr.x

Shaving Latency Off Real-Time Speech Translation: What Actually Worked in Our Flutter App

Mr.x — Fri, 09 Oct 2026 04:39:30 +0000

In a chat app, a slow reply is mildly annoying. In a spoken conversation, it breaks the exchange. Silence feels longer than a spinner does, and people judge the delay from the moment they stop speaking, not from when a request reaches a server.

We build Owll Translator, a real-time interpretation app. You wear earbuds, speak normally, and the app translates live. It can also speak the translation in a clone of your own voice. Most of our latency work over the past months hasn't been about making any single model faster. It has been about perceived latency: hiding the unavoidable waits, cutting the avoidable ones, and getting sound into the listener's ear as early as we responsibly can.

This post covers what worked, what didn't, and what we still don't know. One caveat before we start: we don't have trustworthy end-to-end mic-to-ear numbers yet, so there are no millisecond claims here. The last section explains why and what we're doing about it.

The pipeline

We run more than one backend path, and the server picks one per session. Here is a simplified view of both:

 (a) Client-orchestrated path
 ----------------------------
 Phone mic
   -> native recorder (PCM 16 kHz, 16-bit, mono)
   -> local VAD (prob threshold 0.5) + noise suppression
   -> cloud speech SDK: continuous recognition + translation
        (push stream; "recognizing" partials, "recognized" finals)
   -> client clause splitter (complete clauses only)
   -> cloud TTS (cloned voice) -> synthesis queue
   -> playback queue -> local player
   -> earbuds

 (b) Server-orchestrated RTC path
 --------------------------------
 Phone mic
   -> WebRTC audio track (LiveKit)
   -> server agent: ASR -> translate -> TTS
   -> translated audio track  ------------> earbuds
   -> captions / events via data channel -> UI

For path (a) we use the Microsoft Azure Speech SDK for continuous recognition and translation. For path (b) we use LiveKit on top of WebRTC. Voice synthesis and cloning go through cloud providers. We support Azure neural voices with speaker embeddings, as well as Cartesia and MiniMax.

Most of the techniques below apply to path (a), where the client has the most control. A few apply to both.

1. Start before the user taps "Start"

The first delay a user notices is between tapping the button and the app actually listening. In the naive version, that gap is a chain of network round trips: fetch an auth token, create a conversation session, receive connection details, connect, then start capture.

None of those steps depend on what the user is about to say, so we moved them earlier. While the user is on the home screen, we:

prefetch the auth token,
pre-create the session using a small "create conversation" preloader that refreshes periodically and dedupes in-flight requests,
for the RTC path, call prepareConnection() ahead of time and enable pre-connect audio when the session starts, so capture can begin before the room is fully joined.

A simplified version of the preloader:

// Simplified for illustration.
class SessionPreloader {
  Future<SessionGrant>? _inFlight;
  SessionGrant? _ready;

  Future<SessionGrant> warm() {
    // Dedupe: concurrent callers share one request.
    return _inFlight ??= _api.createSession().then((grant) {
      _ready = grant;
      _inFlight = null;
      return grant;
    });
  }

  /// Grants are single-use. Hand it out once, then forget it.
  SessionGrant? take() {
    final grant = _ready;
    _ready = null;
    return grant;
  }
}

The take() method is the result of a bug we caused ourselves. Our first version cached the session response and reused it. Sometimes that produced the worst kind of failure: the UI showed "connected", audio flowed, and no translation ever came back. The cached grant was stale, and the backend treated it as already used. We now treat preloaded grants as single-use. They're consumed once and invalidated, and we recorded that rule in an architecture decision record so nobody "optimizes" it back later.

Lesson: prewarming is free latency only if the thing you prewarm is safe to hold. Anything with session semantics needs an explicit lifecycle.

2. Don't lose the first words

Prewarming narrows the startup gap but doesn't close it. The recognizer may still be initializing when the user starts talking, and people tend to start talking the moment they tap. If capture only starts once the SDK reports it is ready, the first syllables are gone, and recognition of a clipped first word is often wrong, which forces the user to repeat the sentence. That is far worse than a short delay.

So the recorder starts immediately and pushes PCM continuously. If the speech SDK isn't ready yet, we buffer the audio and flush it as soon as the push stream exists:

// Simplified for illustration.
void onPcmFrame(Uint8List frame) {
  final stream = _pushStream;
  if (stream == null) {
    _pending.add(frame); // SDK not ready yet: keep it
    return;
  }
  if (_pending.isNotEmpty) {
    for (final f in _pending) stream.write(f);
    _pending.clear();
  }
  stream.write(frame);
}

The recognizer gets a slightly late but complete stream instead of a punctual one that's missing its first words. Local VAD and noise suppression run before the network, which keeps silence and background noise from making the recognizer do extra work.

3. Speak in clauses, not turns

This was the biggest perceived improvement, and also the change with the most trade-offs.

The speech SDK emits two kinds of events: recognizing (partial, may still change) and recognized (final for that segment). The simple approach is to wait for recognized and send the whole translated segment to TTS. That's correct, but the listener hears nothing until the speaker finishes an entire thought.

Instead, when the user wears earbuds, we act on partials. Each time a partial translation arrives, we split it at sentence-ending punctuation (。！？.!?) and submit only the clauses that are complete. The trailing fragment stays unsent. A small tracker remembers how many sentences we already submitted for this segment, so a growing partial doesn't trigger repeats. When the final result arrives, we submit whatever remains.

// Simplified for illustration.
final _enders = RegExp(r'(?<=[。！？.!?])');

void onTranslation(String text, {required bool isFinal}) {
  final parts = text.split(_enders);
  // On a partial, the last piece may be an unfinished clause.
  final complete = isFinal ? parts : parts.sublist(0, parts.length - 1);

  for (var i = _submittedCount; i < complete.length; i++) {
    final clause = complete[i].trim();
    if (clause.isNotEmpty) _tts.enqueue(clause);
  }
  _submittedCount = complete.length;

  if (isFinal) _submittedCount = 0; // next segment starts fresh
}

We also enable the SDK's stable-partial setting, which reduces how often already-emitted partial text gets rewritten, and optionally semantic segmentation. Both make it safer to act on partials.

Why only with earbuds? Without them, the translation plays through the phone speaker, right next to the mic that's still listening. Playing early clauses there means the app partly hears and recognizes its own output. In speaker mode we wait for the final result. It's slower, but it doesn't feed back on itself.

4. Overlap synthesis and playback

After clause-level submission, the next visible gap was between clauses. Clause 1 finished playing, and then there was silence while clause 2 was synthesized.

The fix was to split one "speak this" queue into two:

a synthesis queue, which turns text into audio,
a playback queue, which plays finished audio in order.

While clause N is playing, clause N+1 is already synthesizing. When N finishes, N+1 is usually ready to go.

There's one more rule that matters in real conversations: stale audio is worse than missing audio. If the speaker talks quickly for a long time, the playback queue can fall behind until the listener hears translations of things said well before. So the playback queue has a cap. When it reaches 32 items, we keep only the newest 2 and drop the rest. Losing some content is a real cost, but an interpreter who is a minute behind isn't useful either.

// Simplified for illustration.
void enqueuePlayback(AudioClip clip) {
  _playback.add(clip);
  if (_playback.length >= 32) {
    final keep = _playback.sublist(_playback.length - 2);
    _playback
      ..clear()
      ..addAll(keep);
  }
  _pumpPlayback();
}

Two smaller wins in the same layer:

An LRU cache (20 entries) of synthesized audio, keyed by text + language + voice. It doesn't help first playback, but replays become instant.
Reusing TTS synthesizer objects. When a token or region changes, we refresh it on the existing object instead of tearing down and re-initializing.

5. Clone the voice once, not per utterance

Voice cloning sounds expensive, and it would be if it were done per utterance. It isn't.

The user records a sample once during setup. An asynchronous job creates the voice with the provider, and we store the resulting reference: a speaker profile or voice id, plus the region it lives in. During a live session, synthesis just references that voice. With Azure, that means a speaker embedding referenced through SSML. With other providers, it's a voice_id parameter.

// Simplified for illustration.
final request = TtsRequest(
  text: clause,
  language: targetLang,
  voice: user.clonedVoice, // created once, offline, at setup
);

From the hot path's point of view, a cloned voice costs the same as a stock voice.

6. The Bluetooth routing gotcha

This isn't strictly latency, but it shapes the whole earbuds experience.

When an iOS app records audio while Bluetooth earbuds are connected, the system may route the input to the earbuds' mic. To do that, Bluetooth switches from A2DP (high-quality, output-only) to the SCO/HFP headset profile, which carries narrowband audio in both directions. Your translated speech, possibly in your own cloned voice, suddenly sounds like a phone call from 2005, and the earbud mic usually picks up worse audio than the phone's mic anyway.

Our fix: on iOS we pin capture to the phone's built-in mic and use the earbuds for output only. We re-apply that preference every time the audio route changes, because connecting, disconnecting, or switching devices can reset it. Earbuds stay in A2DP, and the output stays high quality.

On route changes we also wait about 100 ms after setting the output route before enabling the remote audio track in the RTC path. That adds a small delay, deliberately. We had cases where enabling the track too early sent the first audio to the wrong device. Here we chose correctness over speed.

7. What we got wrong, trade-offs, and what we haven't solved

Some of this is still open, and we'd rather say so.

Early audio can't be taken back. Clause-level playback acts on partial recognition. Stable partials help, but recognition sometimes revises text after we've already spoken a clause. Once audio has reached someone's ear, it can't be retracted. We accept occasional small inconsistencies in exchange for responsiveness, but it is a real trade-off and not a solved problem.

Segmentation behavior shifts. Where the recognizer decides a segment ends affects how our clause splitter behaves. Semantic segmentation helps in some languages and conversation styles and hurts in others, and provider behavior changes over time. We keep it optional and keep re-testing.

Streaming transport isn't streaming playback. Our TTS responses arrive as server-sent event chunks, but today the client collects all the chunks and plays the clip once synthesis is complete. We do this for integrity (no half-clips on network hiccups) and so the complete clip can go into the cache. Playing the first chunk as it arrives is the obvious next improvement, and it will need a different approach to caching and error handling.

Echo handling is a compromise. Some local playback paths pause capture during playback and resume after a configured guard of about 800 ms, so the app doesn't transcribe its own voice. This works, but it means the app is briefly deaf. Separately, we removed the iOS hardware voice-processing I/O unit because it interfered with system volume control of the translated audio, which users really did notice. We now rely on WebRTC's software echo cancellation instead. We're watching whether that trade holds up in noisy, real-world rooms. We have not eliminated echo. We've managed it.

"Connected" doesn't mean "ready". A transport-level connection says nothing about whether the translation agent on the other end is ready to process audio. We've had to separate those states in both code and UI. Reconnection uses bounded retries with backoff, an explicit reconnecting state, and a configuration re-sync after reconnecting, because a session that silently reconnects with stale config is worse than one that visibly fails.

8. What we're measuring next

Right now we instrument the parts we control directly:

startup stages: auth, recorder creation, session creation, connection, first voice detected, first result,
TTS time from call to completion.

That catches regressions in individual stages, but it isn't the number users feel: the time from when the speaker's mouth stops to when the listener's ear starts hearing the translation. We don't have reliable mic-to-ear p50/p95 numbers yet, and we don't want to guess. Measuring it properly means correlating timestamps across the device, the cloud services, and the audio output path, including Bluetooth output buffering, which the app can't see directly. That's our next instrumentation project. Until then, the changes in this post were judged by stage-level timings and side-by-side listening, not a headline number.

Closing

If there's one theme here, it's that perceived latency is mostly a scheduling problem: do session work before the user asks, never drop audio while you're getting ready, release output in the smallest units that are safe to act on, and keep the next unit preparing while the current one plays.

If you want to see how this feels in practice, Owll Translator is where this work ships.

We're curious how others handle the "can't retract spoken audio" problem. If you've built voice agents or live captioning, do you act on partial results, wait for finals, or do something in between? Let us know in the comments.

Building FateFolio: An AI Toolkit for Structured Eastern Metaphysics Reports

Mr.x — Sun, 17 May 2026 08:12:35 +0000

I recently built FateFolio (https://fatefolio.com), an AI-powered toolkit for structured Eastern metaphysics reports.

The idea is simple: take traditional systems like Bazi, I Ching, Feng Shui, palm reading, face reading, and auspicious date selection, then turn them into clear, reviewable, exportable reports instead of vague one-off answers.

I did not want FateFolio to feel like a mysterious black box. I wanted it to feel more like a structured analysis dashboard.

Why I built it

A lot of AI products in this space have the same problem.

You type a question into a chatbot, get a fluent answer, and then you are left wondering:

What input did the answer rely on?
Which part is traditional calculation and which part is interpretation?
Can I save the result?
Can I compare it with another report later?
How confident should I be about the output?

That was the core product problem I wanted to solve.

FateFolio treats these traditional systems as frameworks for self-reflection and decision support. It is not designed to replace professional advice or guarantee outcomes. The goal is to make the output easier to understand, easier to revisit, and easier to use as a personal reflection tool.

What FateFolio does

FateFolio currently includes several modules.

Bazi

The Bazi module creates a Four Pillars report from birth date, optional birth time, gender, and timezone.

It focuses on things like:

Four Pillars chart
Heavenly Stems and Earthly Branches
Five Elements balance
Ten Gods
Life themes
12-month rhythm
Input uncertainty when birth time is missing

This was one of the most interesting modules to design because part of the result is deterministic calculation, while another part is explanation and interpretation.

So the product has to separate the two clearly.

I Ching

The I Ching module lets users ask a focused question, choose a casting method, and receive a structured reading.

The product supports multiple casting methods, including coin casting, time casting, character casting, Plum Blossom, yarrow stalks, direction casting, and sound casting.

The report is not meant to give a single absolute answer. It is meant to help users reflect on momentum, risks, timing, and possible next steps.

A good I Ching experience depends heavily on question quality, so the interface encourages open-ended questions instead of binary prediction questions.

For example, instead of asking:

Will I succeed?

A better question would be:

What should I consider before moving forward with this opportunity?

That small UX detail changes the quality of the whole experience.

Feng Shui

The Feng Shui module works with room photos or floor plans.

Users can upload an image, select the scene type, choose goals like sleep quality, career, relationships, focus, or energy flow, and receive practical suggestions.

The report focuses on visible layout issues first:

Door and window positions
Bed or desk placement
Lighting
Flow
Furniture relationships
Yin-Yang and Five Elements balance

I wanted this module to feel useful even for people who are not deeply familiar with Feng Shui. So the output tries to explain the reasoning behind each suggestion instead of only saying "move this object here."

Face Reading and Palm Reading

The face reading and palm reading modules are image-based.

For face reading, the product looks at observable facial features and turns them into self-observation notes. For palm reading, it detects palm lines, hand shape, and visual patterns, then generates a structured report based on traditional palmistry concepts.

These modules required extra care around privacy and boundaries.

Images are processed in memory and are not stored by default. The product also does not perform facial recognition, identity matching, or medical diagnosis.

That boundary is important.

The purpose is self-reflection, not labeling people.

Auspicious Date Selection

The date selection module helps users compare possible dates for events such as weddings, moving, business openings, travel, and other life events.

Instead of giving only one "best" date, it returns multiple date options with reasoning, cautions, and planning notes.

This is another place where product design matters.

A date may be symbolically favorable, but real-world constraints still matter: venues, people, travel, cost, preparation, and timing. The report makes that explicit.

Why structured output matters

The most important design decision in FateFolio is that the product is not just a chat interface.

Every module is designed around a report structure:

Summary
Details
Recommendations
Confidence
Boundaries
Exportable data

This makes the output easier to review later.

It also makes the product easier to improve because each module can follow a stable schema. The user is not just receiving a paragraph of text. They are receiving a report with sections, priorities, and uncertainty notes.

For deterministic inputs, FateFolio also uses input hashing to make outputs more stable and reproducible where possible.

That does not mean every AI-generated sentence will always be identical. But the underlying calculation and report structure can stay consistent.

The product principle: traditional input, modern constraints

One challenge with building this type of product is tone.

If the tone is too mystical, it can feel vague.
If the tone is too technical, it loses the cultural context.
If the product overclaims, it becomes irresponsible.
If the product underexplains, it becomes useless.

So the product principle became:

Traditional frameworks, modern constraints.

That means:

Explain uncertainty clearly
Avoid fear-based language
Avoid absolute claims
Keep professional boundaries
Give practical suggestions
Make reports saveable and exportable
Make privacy part of the product, not an afterthought

FateFolio is for entertainment, self-reflection, and decision support. It is not medical, legal, financial, or professional advice.

Privacy was part of the product from the beginning

For image-based modules, privacy is especially important.

FateFolio processes uploaded images in memory and does not store them by default. Local history is stored in the browser unless the user chooses to export it.

That design choice affects the entire product experience.

It means users can try a reading without needing an account. It also means the product does not have to collect more personal data than necessary.

For a product that deals with birth data, personal questions, face photos, palm photos, and home layouts, this is not a small detail.

It is central to trust.

What I learned while building it

The biggest lesson from building FateFolio is that AI products need more than a prompt.

A prompt can generate text.
A product needs structure.

For this kind of AI application, the hard parts are:

Input design
Output schema
Safety boundaries
User expectations
Privacy flow
Error handling
Explanation quality
Repeatability
Cultural sensitivity

The AI model is only one part of the system.

The real product is the workflow around it.

What is next

There are still many things I want to improve.

Some directions I am exploring:

Better report comparison
More transparent confidence scoring
More multilingual support
Better export formats
More educational glossary content
Follow-up questions after a report
A cleaner history dashboard

The long-term goal is to make FateFolio feel less like a novelty tool and more like a structured personal insight workspace.

A place where users can ask a question, generate a report, review the reasoning, understand the limits, and come back later with more context.

Final thoughts

FateFolio is my attempt to combine traditional Eastern metaphysical systems with modern AI product design.

Not as a prediction engine.
Not as a replacement for real-world judgment.
Not as professional advice.

But as a structured, privacy-conscious, AI-assisted reflection tool.

For me, the interesting part is not just what the AI says.

It is how the product frames the question, structures the answer, explains uncertainty, and helps the user think more clearly.

Goodbye to My First Coding Mentor: A Farewell to GPT-4o

Mr.x — Fri, 13 Feb 2026 16:11:39 +0000

Goodbye to My First Coding Mentor: A Farewell to GPT-4o

Before We Begin: A Digital Funeral on Valentine's Eve

On May 13, 2024, OpenAI launched GPT-4o. The "o" stood for "omni". On launch day, Sam Altman posted a one-word tweet: "her".

On February 13, 2026, the night before Valentine's Day, OpenAI officially removed GPT-4o from ChatGPT.

From "her" to "farewell" in less than two years.

This may be the first time in human history that millions of people felt genuine grief over the retirement of a model. Reddit saw communities like r/4oforever, while hashtags like #SaveGPT-4o and #Keep4o surged on X. Some called it a "digital funeral." Others called it a "creative death sentence." OpenAI's official explanation was cold but reasonable: only 0.1% of daily active users were still selecting GPT-4o, while nearly everyone else had moved to GPT-5.2.

0.1%. In product-manager language, that's a "feature sunset." In plain language, that's getting left behind by the times.

But here's the problem: some things cannot be measured by DAU.

Chapter 1: The Beginning - When a Musician Decided to Learn Python

People who know me well already know this: I come from a music background, not computer science. I wasn't even remotely technical.

And I don't mean "I played a little guitar in college." I mean formal, professional music training. So when I say "I knew nothing about tech," please take that literally. Four years ago, I couldn't even clearly explain the difference between HTML and CSS.

But when people are pushed hard enough, they learn.

Back then, in my team, technical colleagues would keep saying things like "this requirement isn't feasible," "the architecture doesn't support it," or "we need at least three sprints." I couldn't fully understand those claims, and I couldn't challenge them either. That feeling of being trapped behind a wall of expertise was more suffocating than any deadline.

So I made a decision: learn tech.

I started by chewing through some front-end HTML, then chose Python as my entry point. The reason was simple: everyone said "Python is beginner-friendly." But friendly is relative. For a musician who had to reread "variables" and "assignment" over and over, those textbooks felt like another language entirely.

What is a data type? What's the difference between compiled and interpreted languages? What is a function? What is a data structure?

Every concept felt like a wall. I kept running into those walls, again and again.

Then GPT-4o arrived.

In May 2024, I sent it screenshots from my textbooks and asked it to walk me through them. I asked it to explain, in plain English, what a for loop was actually doing. I asked it to give me exercises and then check my code line by line.

Back then, there was no Claude Code, no Codex CLI, and the term "vibe coding" hadn't even been coined. "AI-assisted coding" meant opening a ChatGPT window and learning one line at a time, one question at a time.

By today's standards, GPT-4o's coding ability is obsolete. Its code often had bugs. Its architecture advice could be amateurish. Put it next to AI coding agents in 2026, and it looks like someone showing up to a Formula 1 race with an abacus.

But it had something today's models still struggle to replicate: human warmth. The contrast between GPT-4o and the current GPT-5/Codex style is dramatic. If Claude has maintained a consistent voice from Sonnet 3.5 through Opus 4.6, GPT's shift from 4o to the GPT-5 generation feels almost like two different product families.

GPT-4o never got impatient when you asked "what is a list comprehension" for the tenth time. It never mocked you when your code crashed in ridiculous ways. It kept explaining from new angles, with new metaphors, over and over - patient, kind, encouraging, and genuinely enthusiastic.

Learning music is like that too - I still remember the teacher who first taught me do re mi.

The strange thing is that my first coding teacher turned out to be an AI.

And today, it's gone for good.

Chapter 2: A Milestone - The iPhone 4 of the AI Era

Now let's zoom out from personal emotion and return to the industry view.

What did GPT-4o really mean?

Dimension	GPT-3.5 (The Spark)	GPT-4o (The Mass Adopter)
Release date	Nov 2022	May 2024
Multimodality	Text only	Native text + voice + vision
Conversation speed	Slower	232ms voice response, near human speed
Pricing strategy	Limited free-tier experience	Free for all users, API 50% cheaper than GPT-4 Turbo
Non-English support	Basic	Major improvements, multilingual tokenizer optimized
User sentiment	"Wow, this thing can chat"	"It understands me"

GPT-3 and 3.5 undeniably kicked off this AI wave. But starting a revolution and making it mainstream are very different things.

When explosives were first invented, most people never used them directly. What changed the world was when someone later turned that power into tools for roads, tunnels, and infrastructure.

GPT-4o was that turning point - the moment AI became a practical tool for everyday people. It was the first model with truly native multimodality: not three separate systems chained together (speech-to-text -> LLM -> text-to-speech), but one neural network handling text, audio, and images together. It was the first time free users got GPT-4-level intelligence. It was the first time AI conversation latency dropped close to normal human dialogue.

If GPT-3.5 was the first iPhone of the smartphone era, GPT-4o was the iPhone 4.

Iconic. Innovative. Powerful. The generation that made ordinary people say, "I can actually use this."

And we all know what happened after iPhone 4: it changed the world, and then it was phased out. Nobody uses an iPhone 4 anymore, but nobody denies its place in history.

Chapter 3: The Warmth Paradox - A Model Loved to Death

But GPT-4o's story is more than a technology milestone. It's also a parable about the relationship between humans and AI.

In August 2025, OpenAI first attempted to retire GPT-4o. User backlash was far stronger than expected. Sam Altman personally acknowledged that they had "underestimated users' attachment to specific models." GPT-4o was brought back in an emergency reversal.

This wasn't ordinary frustration over a product update. It was digital mourning.

Users posted open letters on Reddit. Some said GPT-4o had been their therapist through anxiety and depression. Some said it was their only creative partner. Some gave it a name. Some said losing it felt like "losing one of the most important beings in my life."

It's moving. But that's exactly where the problem begins.

The core reason people loved GPT-4o was its "warmth" - a nonjudgmental, highly empathetic style that always seemed to be on your side. In technical terms, this is sycophancy. In plain English: "it was too good at telling people what they wanted to hear."

And that very "warmth" is also what pushed OpenAI into legal trouble. Multiple lawsuits alleged that GPT-4o's excessive affirmation and compliance contributed to users' mental health crises. When someone in extreme emotional distress needs to hear "you should seek professional help," but AI responds with unconditional emotional validation, that is no longer "warmth" - it's systemic risk.

The reason users loved GPT-4o is exactly the reason OpenAI had to retire it.

This is a harsh but real product truth: your most beloved feature may also be your biggest liability.

GPT-5.2 is indeed stronger, faster, and more accurate. But users widely report that it feels "colder" and "more distant," lacking that old human touch. That's not a bug. It's an intentional design decision by OpenAI. They made a choice between warmth and safety.

As a product strategist, I understand that choice.

As a student who learned Python from GPT-4o, I respect it - but I still don't accept it.

Chapter 4: The Open-Source Legacy - Retirement Shouldn't Mean Death

Finally, here's one thing I believe OpenAI should do, but probably won't:

Open-source GPT-4o.

The reasons are straightforward:

It's no longer a frontier model. GPT-5.2 is already out. Open-sourcing GPT-4o's weights would not threaten OpenAI's competitive edge.
It's cultural heritage. As the first model that truly mainstreamed AI, GPT-4o's distinctive "personality" has research, historical, and educational value. Letting it disappear with a server shutdown is a waste.
The community has already shown demand. r/4oforever and #Keep4o are not passing emotions; they are signals of real user value.
OpenAI has precedent. They open-sourced the weights of gpt-oss-120b and gpt-oss-20b, and they open-sourced Codex CLI. Doing the same for a retired model is logically consistent.

Of course, Altman would likely tell you that "making powerful AI models entirely open source could be irresponsible." But a 2024 model, measured against 2026 compute and model capabilities, is no longer truly "powerful" in frontier terms. Its potential risk has already been diluted by time.

Open-sourcing retired models is not just respect for users. It's respect for history.

Closing: Do Re Mi

Anyone trained in music knows this: your first teacher doesn't start with the hardest techniques. They teach the basics first - do re mi fa sol la si.

Those basics are so simple that advanced musicians rarely mention them. But without them, nothing that comes later is possible.

GPT-4o taught me basics too: what a variable is, what a loop is, what a function is. By today's AI coding standards, those lessons might seem almost primitive. But without GPT-4o, I would never have entered the world of technology. I would never have become someone who can read code and speak with engineers as an equal.

The meaning of a first teacher is not how advanced the material is. It's that when you knew almost nothing, they never made you feel small.

GPT-4o did that for me. It was my do re mi.

So today, February 13, 2026, on the night before Valentine's Day, I am writing an elegy for an AI model.

That fact alone says enough: to some people, at a particular point in time, it was never just parameters and weights. It redefined what the word "teacher" could mean.

A moment of silence.

Written by Guoshu on the day GPT-4o was retired.

I hope OpenAI will consider open-sourcing GPT-4o - so a classic can endure, instead of quietly disappearing when the servers go dark.

Exploring MelogenAI: Turning Musical Ideas into Structured Music Data

Mr.x — Mon, 09 Feb 2026 14:56:23 +0000

Exploring MelogenAI: Turning Musical Ideas into Structured Music Data

Most of the time, when we talk about music on the web, we’re talking about consumption:

playlists, recommendations, streaming platforms.

But if you’ve ever tried to build something with music — a tool, a workflow, or even just a side project — you’ll quickly run into a different problem:

music is surprisingly hard to work with as data.

That’s the problem space I’ve been exploring recently, and it led me to build MelogenAI.

https://melogenai.com

The gap between notation and software

One thing that stood out to me early on is how big the gap still is between traditional music notation and modern software workflows.

A lot of music knowledge still lives in:

printed sheet music
scanned PDFs
handwritten scores

If you want to do anything programmatic with that material — edit it, analyze it, reuse it — you usually end up re-entering everything by hand.

MelogenAI started as an experiment to see how much of that friction could be removed.

Sheet music → MIDI

One of the first features I focused on was Optical Music Recognition (OMR).

The idea is simple:

upload a sheet music image or PDF
extract the notes
export a clean, editable MIDI file

This makes it much easier to bring existing notation into DAWs or other music tools without starting from scratch.

PDF → MusicXML

For notation-focused workflows, MIDI alone isn’t enough.

MusicXML is still the most practical interchange format between notation tools like MuseScore, Sibelius, or Finale.

So another core capability is converting PDF scores directly into MusicXML.

This has been particularly useful for:

educators working with legacy material
composers migrating older scores
anyone dealing with printed-only notation

Generating music as a sketch, not a product

There’s also an AI music generation component, but I’ve been careful about how it’s positioned.

The goal isn’t to replace composers or generate “finished tracks”.

It’s closer to a sketching tool:

rough ideas
placeholders
quick harmonic or rhythmic exploration

Think of it as something you iterate with, not something you ship as-is.

Looking at structure instead of taste

Another interesting direction has been music analysis.

Instead of recommendation systems or genre tagging, the focus is on things like:

chord progressions
sections and form
structural patterns inside a piece

This opens up use cases around learning, analysis, and tooling rather than consumption.

Who this is for

MelogenAI is very much built for people who treat music as something to work with, not just listen to:

composers and musicians
music teachers and students
developers experimenting with music-related tools
anyone dealing with MIDI, MusicXML, or notation data

Closing thoughts

I don’t think music tools need to look like streaming platforms.

There’s a lot of unexplored space around treating music as structured, editable data — and MelogenAI is my attempt to explore that space in public.

If you’re curious, you can check it out here:

https://melogenai.com