DEV Community: Chris

One Prompt, Four Modalities: What a Unified Generation Agent Actually Has to Solve

Chris — Sat, 26 Sep 2026 13:41:35 +0000

Most generation tools are one modality wide. You have a favourite for images, a
different one for video, something else for voice, and if you touch 3D at all it is
a fourth tab with its own account and its own export quirks.

The obvious fix is to put them behind one text box. That sounds like a UI decision.
It is not. Once a single prompt field has to serve image, video, voice and 3D, three
genuinely hard problems show up, and none of them are about layout.

Problem 1: the modalities disagree about what a prompt is

A good image prompt is a dense noun phrase. Adjectives, materials, lighting, lens.
Nothing about time, because there is no time.

a worn brass desk lamp, single hard key light from the left, dusty highlights

A good video prompt is a verb phrase with a camera in it. The same noun phrase
produces a static shot that technically moves.

a worn brass desk lamp; camera pushes in slowly as the filament flickers on

A good 3D prompt is neither. It is a set of geometric constraints, and half the
adjectives that improve an image actively hurt it — "dusty highlights" is a
texture instruction with no geometry behind it, and "hard key light" is
meaningless in a mesh.

a desk lamp, hollow base, flat bottom, thick shade walls, no thin wires

A voice prompt is a performance direction: pace, register, emphasis.

So a single prompt box is lying a little. The same sentence cannot be optimal in
four places at once. The design question is what to do about that, and there are
three honest answers:

Make the user rewrite it per modality. Correct, and nobody does it.
Rewrite it silently. Fast, and it hides why a result was bad.
Rewrite it and show your work. Slower, and the only option where the user learns anything.

The third is what "agent" should mean in practice: the thing plans, tells you what
it is about to do, and lets you disagree before spending the compute.

Problem 2: each modality fails in an unrelated way

The failure modes have almost nothing in common, which means one generic error
state is useless:

Modality	Typical failure	What the user needs to see
Image	Composition drifts from the brief	A/B against the prompt
Video	Frame-to-frame identity drift	Which frame it broke on
Voice	Right words, wrong performance	The specific phrase to re-read
3D	Geometry is plausible, topology is not	Mesh stats, not a render

That last row is the one people underestimate. A 3D render can look flawless while
the underlying mesh is unusable — hundreds of thousands of triangles, disconnected
shells, no consistent scale. The render is not evidence about the geometry. Any
tool that shows you only the pretty picture is answering a different question from
the one you asked.

Problem 3: chaining is where the value is, and where the state lives

The single-modality workflow is: prompt, generate, download, done.

The interesting workflow is: generate an image, keep that exact subject, put it in a
scene, animate it, add a voice over it, and separately turn the subject into a mesh.

Each arrow in that chain is a place where identity has to survive. That is a state
problem. The system has to carry a persistent handle on "this specific thing" across
model boundaries that were never designed to agree with each other. Tool-hopping
loses that handle at every step, which is why the manual version of this workflow
produces four assets that do not quite look like the same object.

Keeping the chain inside one project is not a convenience feature. It is the only
place the continuity can live.

What this implies for exports

If the chain is the point, the exports have to be ordinary files — MP4, PNG, WAV,
OBJ, GLB — and they have to be downloadable without ceremony.

A generation tool that will not hand over the file is not a tool, it is a demo. This
matters most for 3D, where the file is the entire deliverable: nobody wants a mesh
they can only look at inside someone else's viewer.

The short version

Putting four modalities behind one prompt is not a consolidation exercise. It
requires the system to translate intent per modality, surface modality-specific
failure honestly, and keep subject identity alive across model boundaries. Get those
three right and the single text box is genuinely simpler. Get them wrong and you
have built four tools that happen to share a font.

If you want to see what the chained version feels like — including
AI 3d creation that hands you a GLB rather than a viewer link —
the first render is free, which is about the right amount of commitment for finding
out whether the unified version is worth it.

Why does stylized “cursive text” even render on Instagram?

Chris — Sat, 02 May 2026 04:26:45 +0000

Scrolling through Unicode‑styled bios always raises the same question for me: we’re not uploading fonts, so how are those ornate characters surviving across every app and device? I spent some time poking at Cursive Generator to see what kind of engineering makes that happen, and it’s surprisingly old‑school — closer to a Unicode hack than a graphics pipeline.

Unicode as poor man’s font system

When you type something there and pick “Script” or “Bold Gothic,” the site isn’t drawing custom glyphs; it’s remapping code points. Most of those styles live in the “Mathematical Script,” “Fraktur,” and “Double‑Struck” blocks (U+1D4xx, U+1D5xx, U+1D50x). The generator likely has a static lookup table: ASCII a–z → corresponding decorative characters. When a letter doesn’t exist in that range, it probably falls back to the base Latin, which is why punctuation stays plain.

That interpretation means the whole text field output is still ordinary strings, not rendered images — hence copy/paste works in Instagram or Discord without fonts installed. The key trick is selecting code points that the major OS fonts happen to ship with glyphs for, like Cascadia, SegoeUIEmoji, or Apple Color Emoji. “Generates across platforms” is less magic, more exploitation of those built‑in fonts.

PNG generation hints

The landing page mentions downloadable PNGs for “wedding” or “Etsy designs.” That points to a canvas‑based renderer separate from the Unicode mapping path. My guess is an <canvas> or <svg> layer that uses Google Fonts under OFL — probably dynamically loaded via the Google Fonts CSS API once the user clicks “Image.” The PNG export could be canvas.toDataURL() or a Blob converted for download.

The absence of server latency (images appear instantly) implies client‑side rendering only; no headless Chrome round‑trip. Cloudflare presence in headers suggests purely for CDN + DDoS protection, not computation.

Astro front‑end observations

The DOM fingerprints show Astro v6 and TailwindCSS. That fits the static‑site profile: layout generated at build time, minimal JS hydration except for the generator input logic. Given Astro’s islands model, the state machine for style selection is probably a reactive miniature component — maybe written in Svelte or React nested inside the Astro page. It doesn’t look like any heavy framework is present; just small hydration islands and a single script handling copy/download actions.

One subtle optimization I noticed: loading “10 more styles” doesn’t re‑render the whole layout. That points to pre‑fetched fragments or data attributes toggled via DOM mutation instead of network fetches. Very low overhead, typical of Astro partial hydration.

Speculative internals

Two small engineering guesses:

Lookup compression — with 42 styles × ~60 supported characters, a naïve map would be thousands of entries. They might autogenerate this from Unicode ranges, not hardcode. Could be a JSON slice pre‑compiled during Astro build and embedded in the bundle.
PNG font rasterization — likely using OffscreenCanvas plus FontFace API. It would allow asynchronous font loading while keeping main‑thread responsive, explaining the lack of flicker when changing script styles.

What I'm still curious about

PNG exports seem crisp even at large sizes — possibly vectorized before rasterization. Is the download actually a rendered canvas bitmap, or are they producing SVG and then rasterizing via a hidden <img> to get transparency? I couldn’t confirm from the client code alone. If it’s the latter, that’s a neat hybrid I’d like to see more of.

The bellows move, but the CPU stays quiet — what’s powering this browser based harmonium?

Chris — Sun, 19 Apr 2026 12:11:48 +0000

The bellows move, but the CPU stays quiet — what’s powering this browser web harmonium?

Clicking into this harmonium-in-a-tab feels a bit surreal: a little bellow handle animates, reeds respond to keypresses, and the sound is surprisingly organic for something coming out of AudioContext. I'm less interested in how musical it feels than in how they pulled off that “real instrument in a browser” illusion with so little lag.

Probably sample playback, not synthesis

The page claims “nine sampling points across three octaves,” which suggests pre‑recorded WAVs pitched via resampling rather than additive synthesis. My guess is each note name maps to an AudioBuffer loaded once and stretched by playbackRate. Because harmonium reeds are relatively static timbrally, a few samples per octave are enough if you interpolate pitch carefully — maybe detune in 25‑cent steps.

What’s impressive is the lack of audible pops between bellows volume changes; that implies they’re smoothing gain adjustments through a shared GainNode envelope, not tweaking volume directly on AudioBufferSourceNode. The “pump handle” UI probably just changes a target amplitude, and a short exponential ramp handles the fade so the CPU doesn’t glitch.

MIDI velocity and the mystery of expression

The velocity‑sensitive response hints at simple amplitude mapping, but the harmonium doesn’t actually respond to velocity in the acoustic sense — it’s air pressure. Maybe they map velocity onto the global bellows gain, making harder hits simulate stronger pressure. Without polyphonic aftertouch, that would still feel static if you hold notes. I’d bet they’re smoothing gain.value over time to fake air compression.

The navigator.requestMIDIAccess API can be finicky in Safari, so I’d love to see what polyfill (if any) they use. The low latency suggests they rely on Chrome’s direct MIDI path and accept best‑effort elsewhere.

The “drone” is a separate audio graph

Switching between the reed drone and tanpura loop is instant, no browser re‑buffering pause. That implies pre‑decoded looping buffers. The tanpura’s periodicity sounds about five seconds, so they likely run a looping AudioBufferSourceNode with a small crossfade fade‑out/fade‑in at the seam. The harmonium drone could simply be the same sample layered under a low‑pass filter.

Given that it keeps playing while you record, the recorder must be grabbing from a mix MediaStreamDestination feeding into a MediaRecorder — straightforward but clever for an all‑client setup.

Recording and share links

Recordings save as WebM up to two minutes, which lines up neatly with Chrome’s default MediaRecorder memory limits; beyond that, latency spikes. The “one‑hour share link” that supposedly stores the state is probably a compressed JSON blob passed via base64 — about forty characters on my short test, so likely LZ‑compressed settings encoded into the query string. Interesting that playback settings, not audio, travel in that link; the recipient just rebuilds the same instrument state client‑side.

PWA and caching puzzle

The thing installs offline, so they’ve gone the serviceWorker route. But harmonium samples are big — three octaves × nine notes ≈ 27 files at maybe 300–500 KB each. That’s bandwidth‑heavy. Either Cloudflare is edge‑caching aggressively, or they lazy‑cache samples on first touch. Watching the network panel shows delayed fetches per note, supporting the lazy hypothesis. Makes sense: cache only notes actually played rather than forcing a multi‑megabyte warm‑up.

What I still wonder

The bellows animation tracks volume with almost zero frame lag on mid‑range phones. Are they syncing that via an AudioWorkletProcessor thread posting back amplitude RMS values, or just deducing handle position purely from UI state? If anyone has dug through its JavaScript bundle, I’m curious how tightly (or loosely) the visual and audio loops are coupled.