gramps
de81fa3c5d
Pre-1.0 the creator streams in one instance and screen-captures it from another. Nothing prevented a second instance - there is no single-instance mutex and no port anywhere. What broke it was SHARED STATE, and two of the collisions were hard failures rather than annoyances: - the layout DB. The model is read-whole-scene / write-whole-scene, so two instances saving different layouts clobber each other. - the WebView2 user data folder. Chromium takes an exclusive lock on it, so the second instance of the same exe does not start at all. - the auth token store. A test instance would overwrite the real YouTube sign-in with its own. - startup.log, where two appenders interleave and a crash in either instance becomes ambiguous. Set YTLIVE_INSTANCE=<id> and the process gets a private root at %APPDATA%\ytLlive\instances/<id>/ for those four. Recording folder and the ffmpeg tools cache stay shared on purpose - the cache should be shared, and the creator picks the record folder. Global hotkeys stay un-namespaced: if both instances register the same one, Windows refusing the second is the correct answer. An id that is not letters/digits/dash/underscore is rejected and degrades to the primary profile, so the variable can never walk out of the profile directory or name a UNC path. The entire implementation is inside #if DEBUG. A Release build compiles to DataRoot => DefaultRoot and WebViewDataFolder => null, and the call sites are unconditional so Release cannot drift by forgetting an #if. The harness lives with the tests: InstanceIsolationTests covers the two-identities contract, the primary-instance no-op, per-instance WebView folders, path-traversal rejection, that the real output paths actually move with the profile, and a source-level assertion that the #else arm IS production behaviour. Verified against a real Release build: the InstanceVariable field is absent from its metadata and no "instances" path segment survives, while DataRoot and WebViewDataFolder are present in both configurations. Grepping for YTLIVE_INSTANCE proves nothing - a const is inlined at compile time and appears in neither build, which cost one wasted verification round. Docs for this unit (the InstanceProfile paragraph in ai.md, the 1.0 gate in TASKS.md, and the MyMistakes/HANDOFF entries) landed in the previous commit, because they share those files with the branding-credit work.
ytLlive
A creator-proof live-streaming and recording app for YouTube — native Windows (C# / WPF / .NET 8).
Screenshot
Design Principle
This software is so intuitive that even the most right-brained person can easily intuit and use it.
Every feature is measured against this. One-click go-live, sane YouTube defaults, visual scene building, and no dead ends — every action has a visible outcome.
Why ytLlive
OBS treats YouTube as an afterthought; SLOBS is Twitch-first with YouTube bolted on. ytLlive is designed and dedicated to YouTube livestreaming and recording, and to YouTube's specific quirks.
Account Assumption
ytLlive assumes you already have a YouTube creator account — connecting uses "Sign in with Google" to link that existing account. ytLlive does not create accounts. If you don't have a YouTube channel yet, set one up on YouTube first, then connect it here.
Audio Assumption
ytLlive uses your default microphone and desktop/game output — it never hunts for a device or contends for one. It assumes your audio is already configured and working (default input and output set, not hijacked by another app). Audio issues are a Windows/device matter outside ytLlive's scope: we don't debug, detect, or try to fix them. If it doesn't sound right, fix the system's audio settings first — it's on the OS, not on us.
Run
dotnet build # Windows only — WPF
dotnet run
Version Roadmap
v1 is the finished product (creator ruling, 2026-09-01 — there are no v1.x releases).
Everything still queueing lands in v1; anything not on the feature list is on the closed
"Out of product — permanently" list in TASKS.md — read that page before asking for a feature.
What v1 ships: the five-scene director's control surface, webcam + screen capture, media + web + text sources, chat on-stream, the social bar, mic/desktop audio with auto-duck and TRAX, local recording, variable quality tiers with auto step-down, one-click go-live + scheduling, stream resilience (auto-reconnect inside YouTube's grace, one-click back on air), built-in monetization awareness (reward capture, session reports, YPP journey tracker), Alerts — all free and ungated; the one-time license only removes the branding flash.
Structure
| Path | Role |
|---|---|
Models/ |
Scene, Source, WebcamSceneConfig, SceneElement, SceneCatalog, QualityOption, StreamConfig/Health, chat, Socials, BroadcastMetadata, Music, MicStatus |
ViewModels/ |
MainViewModel (partial classes per area) + dialogs: GoLive, CameraPicker, MicPicker, HotkeyConfig, Socials, LiveBroadcastForm |
Services/ |
YouTube (OAuth, streams/broadcasts, chat polling), LayoutStore (SQLite), capture (camera/screen-capture/media-file via FFmpeg), SceneCompositor + FramePump, FFmpeg encoder + RTMP, audio pipeline (WASAPI loopback + mic, mixer, filters, ducker, limiter, TRAX), SocialValidator, notifications, hotkeys, SceneGraph, ChatOverlayLayer |
Helpers/ |
ViewModelBase, RelayCommand, ImageCache, AppLog, TokenStore (DPAPI), OAuthCredentials, converters |
Themes/ |
Controls.xaml — the dark-theme control styles, merged once in App.xaml |
MainWindow.xaml |
Dark-theme control surface: thumbnails + central preview, two-state left panel (layers/properties ↔ live chat), top bar, footer |
Distribution.md |
GA-time plan: signing, installer, EULA, hardening — executed as TASK 36 |
Docs (memory map)
schema.md defines the conventions; ai.md is the AI/session guide;
TASKS.md is the task queue. Each code directory carries an index.md.