Write. Rehearse. Read. Go live. All from the browser.
An open-source, browser-first teleprompter studio built around TPS so the same script can move from first draft to rehearsal, reader mode, recording, and live delivery without a backend.
Try it now · GitHub · TPS · Architecture · Run locally · License
If you speak on camera, stream, or present live, the workflow usually fragments immediately. Drafts live in one app. Rehearsal happens somewhere else. The teleprompter is a separate tool. Recording and streaming need another stack entirely. Every switch breaks context, strips timing cues, and turns delivery into a copy-paste problem.
PrompterOne keeps that flow in one browser tab. You write once in TPS, rehearse the same script in Learn, read it in the teleprompter, and send the same composed program feed into local recording or transport-aware live output. Pacing, emphasis, structure, metadata, and reader settings stay attached to the script instead of getting rebuilt at every stage.
No PrompterOne backend. No desktop install. No account wall. Open the app, start writing, and keep the runtime in the browser.
- Library: browse scripts, create folders, move documents, search by title, file name, and script content, then jump straight into edit, Learn, or Teleprompter flows from the same card.
- Editor: author real TPS with Monaco-native syntax support, metadata hydration, structure-aware navigation, floating formatting controls, in-document find, syntax-aware rendering, browser-local autosave/history, a script knowledge-graph view, and responsive large-draft typing.
- Learn: rehearse with ORP-aligned RSVP, context rails, phrase-aware timing, WPM controls, stepping, looping, and punctuation-safe word progression.
- Teleprompter: read with persisted font and width controls, focal-line positioning, horizontal and vertical mirror toggles, orientation switching, browser fullscreen, segmented progress, and optional camera background.
- Onboarding: walk the first-run flow with a localized tour that explains TPS, RSVP, the editor, Learn, Teleprompter, and Go Live, then reopen that tour later from Settings.
- Settings: manage appearance, browser language, media permissions, camera and microphone setup, sync offsets, recording defaults, AI provider preferences, cloud snapshot targets, transport credentials, and onboarding restart from one routed screen.
- Go Live: run the browser-owned studio shell and save the composed program feed locally with decodable video and audio while remote transport and destination routing continue to expand.
The operating desk for the rest of the app. The library keeps starter scripts and your own documents in browser storage, supports nested folders, lets you search by title, file name, or body text, and branches straight into editing, rehearsal, or reading from the same card. It is built for quick route switching instead of export-import churn.
This is not a plain textarea. The editor understands TPS (Teleprompter Script), so you can write in segments, blocks, pacing markers, emphasis, emotion tags, pronunciation guides, pause cues, and speed modifiers directly in the source. Front matter is parsed into the metadata rail and kept out of the visible body instead of lingering inline.
The authoring surface includes structure navigation on the left, a full formatting and insert toolbar, floating selection controls, a metadata rail for front matter and speed offsets, in-document find, import and export actions, browser-local autosave with revision history, syntax-aware highlighting over the live source, and a first-class script graph tab. The graph view can run beside or over the source, lets writers inspect the script's high-level knowledge map, and keeps jump-back-to-source context attached to graph nodes. Recent UI work moved TPS authoring fully onto the Monaco editor surface, tightened dropdown and tooltip behavior, cleaned up gutter spacing, and kept large-draft responsiveness intact on both polished demo scripts and very large seeded drafts.
PrompterOne treats TPS cues as reading instructions, not markup noise. The editor and reader now carry the same cue intent forward for voice, delivery, pace, emphasis, highlight, pronunciation, phonetics, stress, breath marks, staccato, legato, energy, melody, edit points, speaker/archetype metadata, aside, rhetorical turns, building delivery, sarcasm, loud, soft, whisper, warm, urgent, and related emotion cues.
In the editor, TPS authoring stays readable while Monaco colors cue tags, underlines articulation, and keeps pronunciation and delivery hints visible beside the clean script text.
In the teleprompter, the clean reading line keeps those cues visible through music-inspired reading marks: pace changes affect timing and word shape, slower cues widen the word, faster cues keep bounded non-overlapping tracking, loud cues get larger and weightier, building delivery adds a crescendo-style hairpin, breath and pause cues read like rests, legato uses a music-like slur, staccato uses dots, and energy or melody adds stronger visual rhythm without exposing raw TPS tags. The notation model follows common score-reading conventions for slurs, staccato, and crescendo hairpins from music notation references such as List of musical symbols and Music Theory Academy's dynamics guide.
The screenshot matrix below is generated from test-tps-cue-matrix.tps. Each row uses one plain reader card, one normal sentence, and one isolated cue scope. The central focus word names the cue whenever possible, for example [sad]sad[/sad], plus phrase-span examples where TPS tags intentionally wrap a short cue phrase.
| TPS cue | Reader meaning | Visible reader treatment | Reader screenshot |
|---|---|---|---|
| Structure baseline | Plain block text with no inline cue | Shows the clean reading sentence and segmented card shape without raw TPS headers |  |
/ |
Short pause before the next word | Adds one compact rest marker before the central word while keeping the spoken word clean |  |
// |
Stronger short pause before the next word | Adds one visible rest marker before the central word without exposing the slash text |  |
[pause:500ms] |
Explicit half-second rest | Renders a pause cue before the central word and preserves phrase spacing |  |
[pause:1s] |
Explicit one-second rest | Renders a pause cue before the central word and keeps the next word readable |  |
[breath] |
Breath cue | Renders a breath rest before the central word without turning the cue into spoken text |  |
[xslow] |
Extra-slow pace | Broadens the central word with visibly airy tracking, wider word shape, and slower timing |  |
[slow] |
Slow pace | Opens and broadens the central word while preserving readable gaps |  |
[normal] |
Reset to normal pace | Returns the central word to the base pace treatment |  |
[fast] |
Fast pace | Tightens the central word with compact tracking and faster timing |  |
[xfast] |
Extra-fast pace | Makes the central word visibly narrower without colliding with neighbors |  |
[180WPM] |
Explicit WPM pace | Maps the central word to a measured fast timing and compact spacing contract |  |
[loud] |
Strong vocal intensity | Makes the central word visibly larger and weightier with a warmer projected tone |  |
[soft] |
Softer delivery | Uses a smaller, lighter, cooler treatment while keeping the central word legible |  |
[whisper] |
Whispered delivery | Uses a smaller, airy italic treatment with subdued opacity and dotted texture |  |
[warm] |
Warm emotional tone | Tints the central word with an amber/orange warm treatment |  |
[urgent] |
Urgent emotional tone | Gives the central word a red/crimson urgent treatment |  |
[excited] |
Excited emotional tone | Gives the central word a magenta/violet excited treatment |  |
[happy] |
Happy emotional tone | Tints the central word for upbeat delivery |  |
[sad] |
Sad emotional tone | Tints the central word with a lower-intensity mood |  |
[calm] |
Calm emotional tone | Keeps the central word muted and steady |  |
[energetic] |
Energetic emotional tone | Gives the central word a stronger active treatment |  |
[professional] |
Professional emotional tone | Keeps the central word controlled and formal |  |
[focused] |
Focused emotional tone | Highlights the central word as concentrated delivery |  |
[concerned] |
Concerned emotional tone | Uses a concerned tint on the central word |  |
[motivational] |
Motivational emotional tone | Gives the central word an encouraging emphasis |  |
[neutral] |
Neutral tone reset | Returns the central word to neutral delivery even inside a warmer block context |  |
[aside] |
Aside delivery shape | Gives the central word a delivery-specific aside cue |  |
[rhetorical] |
Rhetorical delivery shape | Marks the central word with a rhetorical treatment |  |
[building] |
Building delivery shape | Adds a crescendo-style hairpin and progressive weight so delivery can rise through the phrase |  |
[sarcasm] |
Sarcastic delivery shape | Marks the central word with a sarcastic delivery cue |  |
[legato] |
Smooth articulation | Adds a music-like curved slur below the central word |  |
[staccato] |
Clipped articulation | Adds clipped music-like dots below the central word |  |
[energy:8] |
High intensity contour | Adds stronger energy weight and rhythm to the central word |  |
[melody:3] |
Melodic movement | Adds a subtle melodic contour to the central word |  |
[highlight] |
Editorial highlight | Uses a shaped translucent marker background behind the cue word without broken half-height fills |  |
[emphasis] |
Editorial emphasis | Uses a stronger word shape and weight treatment without connector underlines between words |  |
| Markdown bold | Strong editorial emphasis | Shows a heavier bold word shape without raw markdown markers |  |
| Markdown italic | Light editorial emphasis | Shows a visibly slanted italic word shape without raw markdown markers |  |
[pronunciation:/prəˌnʌnsiˈeɪʃən/] |
Pronunciation note | Uses the guide itself as the primary reader text and keeps the original spelling as compact secondary context |  |
[phonetic:/fəˈnɛtɪk/] |
Phonetic note | Uses the phonetic guide itself as the primary reader text and keeps the original spelling as compact secondary context |  |
[stress:rising] |
Stress guide | Adds a stress mark and double underline so rehearsal stress is separate from emphasis and bold |  |
[edit_point] |
Production cut point | Stays out of the spoken word while leaving a compact standard edit marker before the next word |  |
[edit_point:medium] |
Medium production cut point | Stays out of the spoken line and adds a stronger medium-priority edit marker |  |
[edit_point:high] |
High production cut point | Stays out of the spoken line and adds the strongest high-priority edit marker |  |
Speaker:Narrator |
Speaker metadata | Keeps persona metadata in validation, graph, and optional chrome without raw reader text |  |
Archetype:Coach |
Archetype metadata | Keeps delivery persona metadata for validation, graph, and assistant context without decorative reader styling |  |
[slow]slow cadence[/slow] |
Phrase pace span | Applies the same slow timing and open tracking across a two-word cue phrase |  |
[urgent]urgent cadence[/urgent] |
Phrase emotion span | Applies the urgent color treatment across a two-word cue phrase |  |
[loud]loud cadence[/loud] |
Phrase volume span | Applies stronger vocal weight and tone across a two-word cue phrase |  |
[building]building cadence[/building] |
Phrase delivery span | Applies one crescendo-style hairpin and progressive build treatment across the two-word cue phrase |  |
[legato]legato cadence[/legato] |
Phrase articulation span | Applies one smooth legato slur across the two-word cue phrase |  |
The full implemented rendering contract, animation constraints, and verification evidence are recorded in TPS Cue Rendering Specification.
The app now opens with a guided first-run tour instead of expecting you to infer the workflow from the chrome. It explains what PrompterOne is for, why TPS exists, what RSVP rehearsal does, how the editor differs from Learn and Teleprompter, and what Go Live is responsible for in the browser-owned studio flow.
The tour is localized, can be dismissed if you already know the app, and can be reopened later from Settings when you need the full product map again.
Learn is the rehearsal surface. It presents one word at a time using RSVP (Rapid Serial Visual Presentation) with an ORP-style focal point so the eye lands in a predictable place even as word lengths change.
Context rails show nearby words without clipping into the focal lane, phrase-aware pauses come from the TPS source, and speed is adjustable while you rehearse. Step controls, loop mode, stop-at-end behavior, and sentence-local context make it useful for both memorization and pacing work before you step into the reader.
The delivery surface. Large readable text, phrase-aware emphasis, adjustable font size, adjustable reader width, and a focal guide you can reposition without leaving the route. TPS formatting carries through here too: speed modifiers affect timing while preserving readable word gaps, inline emphasis stays intact, punctuation is attached correctly, and emphasis groups stay continuous instead of breaking word by word.
A live camera feed can run behind the reader as a background layer, and the operator controls stay on-screen: horizontal mirror, vertical mirror, reader orientation toggle, browser fullscreen, font controls, width controls, focal positioning, segmented block progress, and transport-style playback controls all live inside the same reader shell. Smooth block-to-block transitions keep the reading flow readable in both forward and backward navigation.
Reader preferences persist between sessions, so your chosen layout, focal position, mirrors, and camera background do not have to be rebuilt every time.
A browser-owned studio session. PrompterOne captures a composed program feed directly in the browser, so canvas composition, audio monitoring, and source switching stay client-side.
Local recording saves the composed feed to a file on your machine and is the strongest part of the current live stack. Remote publishing is transport-aware through LiveKit and VDO.Ninja: the browser keeps one real upstream transport path active for a session, and downstream targets are routed or blocked according to what that transport can actually service.
Distribution targets such as YouTube, Twitch, and custom RTMP are capability-gated: unsupported paths are blocked instead of being faked. PrompterOne does not hide a private relay tier behind the UI. The browser remains the only app runtime.
| Settings | Go Live |
|---|---|
 |
 |
Settings holds the operational state for the rest of the app: appearance, browser language, cloud snapshot targets, camera selection with preview, microphone setup with live meters, delay and sync offsets, output quality profiles, recording defaults, AI provider preferences, transport credentials, and onboarding restart. Theme changes and layout preferences persist, and appearance changes propagate across tabs instead of drifting out of sync.
PrompterOne negotiates the initial language from your browser and remembers your explicit choice after that. The routed chrome, onboarding, diagnostics, settings, library actions, editor command surfaces, cloud sync status, AI Spotlight shell, and core reader controls all use the shared localization catalog across English, German, Spanish, French, Italian, Portuguese, and Ukrainian. Technical protocol names, API-key examples, and product brand text stay intentionally unlocalized.
graph LR
A["Library<br/><sub>browse & organize</sub>"] --> B["Editor<br/><sub>write with TPS markup</sub>"]
B --> C["Learn<br/><sub>rehearse at speed</sub>"]
C --> D["Teleprompter<br/><sub>read on camera</sub>"]
D --> E["Go Live<br/><sub>record & stream</sub>"]
Every stage works with the same script. Pacing, emphasis, structure, and metadata you add in the editor show up in rehearsal, in the teleprompter, and in the live session. No re-importing, no copy-paste, no format conversion.
PrompterOne is in active alpha: the core authoring, rehearsal, reader, and local-recording flow is solid now; remote publishing and portability layers are still expanding.
| Area | Status | Current reality |
|---|---|---|
| Library | ✅ | Script browsing, folder organization, create and move flows, workflow launchers, persisted browser storage |
| Editor | ✅ | Monaco-native TPS authoring, front-matter hydration, metadata rail, floating formatting controls, in-document find, script graph tab, local autosave/history, syntax-aware cue rendering, responsive large-draft typing |
| Learn | ✅ | ORP-aligned RSVP, phrase-aware timing, context rails, WPM controls, stepping, looping, punctuation-safe progression |
| Teleprompter | ✅ | Reader width and font controls, focal positioning, TPS cue contour rendering, horizontal and vertical mirror toggles, orientation toggle, browser fullscreen, segmented progress, persisted layout |
| Onboarding | ✅ | Localized first-run walkthrough plus Settings-driven tour restart |
| Settings | ✅ | Appearance sync, browser language, media permissions, camera and mic setup, delay offsets, recording defaults, AI provider preferences, cloud snapshot forms, transport configuration |
| Local recording | ✅ | Browser-side recording of the composed program feed with decodable video and audio |
| Localization | ✅ | Browser-negotiated language, persisted manual override, shared resource parity across supported languages, localized onboarding, diagnostics, settings, library actions, editor command surfaces, AI Spotlight shell, and reader controls |
| Go Live studio shell | ✅ | Source rails, scene switching, preview/program layout, runtime telemetry, session chrome, browser-owned operator workflow |
| VDO.Ninja transport | 🟡 | Real transport-aware browser integration, with operational polish still expanding |
| LiveKit transport | 🟡 | Real transport-aware browser integration and guest-path work, with operational polish still expanding |
| Distribution routing | 🟡 | Targets are capability-gated and blocked when the selected transport cannot service them |
| Cloud storage snapshots | 🟡 | Browser-local provider configuration ships now; broader import/export maturity is still expanding |
| AI provider execution | 🟡 | Provider settings and UI hooks exist, but full runtime execution is still gated behind honest provider integrations |
| Generic RTMP fan-out | ❌ | Intentionally unsupported without a real upstream transport path |
| PrompterOne backend | ❌ | By design: the browser is the only app runtime |
These are product directions, not release-date promises.
Near term:
- Remote publish polish for VDO.Ninja and LiveKit transport flows
- Broader cloud portability for scripts, settings, and snapshots
- More public documentation and real-world workflow examples
After that:
- Stronger guest and destination-routing workflows on top of the browser studio
- AI-assisted writing once provider integrations are real enough to document honestly
- Deeper operational telemetry and operator ergonomics in Go Live
Requirements: .NET 10 SDK
git clone https://github.com/managedcode/PrompterOne.git
cd PrompterOne
dotnet run --project src/PrompterOne.WebOr just open app.prompter.one — no install needed.
PrompterOne is a standalone Blazor WebAssembly app on .NET 10. The browser is the runtime: media capture, composition, recording, and transport-aware output happen through browser APIs such as MediaDevices, WebRTC, MediaRecorder, Web Audio, and Canvas. Transport integrations use LiveKit and VDO.Ninja. Verification uses TUnit, bUnit, and Playwright, with browser scenarios acting as the main release bar. Deployment is a static GitHub Pages build.
dotnet build ./PrompterOne.slnx -warnaserror
dotnet test @./tests/dotnet-test-progress.rsp --solution ./PrompterOne.slnx
dotnet format ./PrompterOne.slnx
dotnet test @./tests/dotnet-test-progress.rsp --project ./tests/PrompterOne.Core.Tests/PrompterOne.Core.Tests.csproj --coverage --coverage-output-format cobertura
dotnet test @./tests/dotnet-test-progress.rsp --project ./tests/PrompterOne.Web.Tests/PrompterOne.Web.Tests.csproj --coverage --coverage-output-format cobertura
dotnet test @./tests/dotnet-test-progress.rsp --project ./tests/PrompterOne.Web.UITests.Shell/PrompterOne.Web.UITests.Shell.csproj --coverage --coverage-output-format cobertura
dotnet test @./tests/dotnet-test-progress.rsp --project ./tests/PrompterOne.Web.UITests.Studio/PrompterOne.Web.UITests.Studio.csproj --coverage --coverage-output-format cobertura
dotnet test @./tests/dotnet-test-progress.rsp --project ./tests/PrompterOne.Web.UITests.Editor/PrompterOne.Web.UITests.Editor.csproj --coverage --coverage-output-format cobertura
dotnet test @./tests/dotnet-test-progress.rsp --project ./tests/PrompterOne.Web.UITests.Reader/PrompterOne.Web.UITests.Reader.csproj --coverage --coverage-output-format coberturaArchitecture and ownership boundaries are documented in docs/Architecture.md. Each project has a local AGENTS.md that describes purpose, entry points, and rules for that area. Feature docs live in docs/Features/.
- LiveKit and VDO.Ninja for transport infrastructure
- cameron/squirt for RSVP inspiration
- Inter, JetBrains Mono, Playfair Display
- Feather Icons
- Deployed on GitHub Pages