[Community] h3.c-studio — a bilingual web GUI for h3-metal

[skaiy]

Hi Salvatore & community — first of all, thank you for h3-metal. The clean public API in h3.h (frame/progress callbacks, cache control, the full h3_params surface) made it a joy to build on.

I've put together h3.c-studio, the second web GUI for h3-metal, as a fork that adds a studio/ directory without touching the engine itself:

🔗 https://github.com/skaiy/h3.c-studio

What it does

• 🎛 Prompt studio — Scene / Action / Camera / Look / Audio structured editing (Context-IR style), canvas sizes, 1–15s duration, speed/quality presets, seed control
• 🖼 Conditioning UI — first/last frame anchors and ordered Ref2VA reference images with drag upload
• 📈 Live progress — per-phase progress bar (text encode → denoise → VAE decode) with streaming logs, cancellable jobs, serial GPU queue
• 🎞 Clip library — auto-indexed generation history with in-browser playback
• 🔗 Chain last frame — one click extracts any clip's last frame into the next generation's --first-frame, which makes the multi-shot storyboard workflow (validated in the README tutorial) practical
• 🌐 i18n — 中文 / English switch

Stack: React + TypeScript + Vite + Tailwind frontend, FastAPI backend wrapping the CLI (moving to a direct libh3.a binding is on the roadmap, since the public API already exposes everything needed for in-process previews).

Licensing: engine stays MIT © antirez, untouched; everything in studio/ is Apache-2.0. Model weights are not included and the README links to the MiniMax community license.

What's next: this is very much a living experiment. I plan to keep evolving the studio — direct libh3.a binding for in-process live previews, a multi-shot storyboard board, prompt templates, maybe a job queue with presets — I honestly don't know how far it will go, but I want to try, and I'll keep shipping in the open.

Feedback, issues and PRs are very welcome — and if you'd ever like to link it in the README, I'd be honored. 🙇

---

中文版

首先感谢 h3-metal —— h3.h 里干净的公共 API（帧/进度回调、缓存控制、完整的 h3_params）让二次开发非常愉快。

我做了 h3.c-studio——h3-metal 的第二个图形界面，以 fork 方式新增 studio/ 目录，引擎本体零改动：

🔗 https://github.com/skaiy/h3.c-studio

• 🎛 提示词工作室：五段式结构编辑、画幅/时长/预设/seed
• 🖼 条件输入：首尾帧锚点 + Ref2VA 参考图拖拽上传
• 📈 实时进度：分阶段进度条 + 日志流 + 任务队列
• 🎞 作品库 + 🔗 末帧接力（一键用上一条末帧做下一条首帧，多镜头叙事工作流）
• 🌐 中英双语

协议：引擎保持 MIT 不动，studio/ 为 Apache-2.0；仓库不含模型权重。

后续计划：这会是一个持续更新的实验——直连 libh3.a 做进程内实时预览、多镜头分镜板、提示词模板库……说实话不知道最终会做成什么样，但想试一试，会持续在开源中迭代。

欢迎 issue / PR，如果 README 愿意收录链接，不胜荣幸 🙇

[skaiy]

Update 2026-09-14 — Storyboard view, demo video, Turbo preset, resumable checkpoints / 更新：分镜板、演示视频、Turbo 预设、断点续跑

Two weeks in, still shipping. What's new since the first post:

• 🎬 Storyboard view — multi-shot cards with per-shot prompt/canvas/seconds/seed, automatic last-frame chaining between shots, and one-click lossless concat. The workflow used to produce a 30-second three-shot noir piece (see demo).
• ⚡ Turbo 6-step preset — folded larryvrh/MiniMax-H3-Turbo-Lora into the checkpoint (via PR Distilled 5-6 step sampling via folded Turbo LoRA, plus three fixes #14's tools/fold_turbo_lora.py), wired as a one-click preset and a per-shot toggle in the storyboard.
• ⏸ Resumable checkpoints in the UI (from PR Add resumable generation checkpoints #2) — pause a long render at step N for a sigma-zero draft, resume to finish if the direction looks right.
• 📹 Demo video + screenshots in the README — 28-second storyboard walkthrough, recorded against the real UI.

Also absorbed upstream community PRs #62, #35, #9, #31 (progress reporting & robustness), and published a comparison doc: h3.c vs other stacks.

首次发布后的两周，持续更新中：

• 🎬 分镜板：多镜头卡片、自动末帧接力、一键无损拼接（演示视频就是用这个功能做的 30 秒三镜短片）
• ⚡ Turbo 6 步预设：Turbo LoRA 已折叠进 checkpoint，预设卡和分镜板镜头开关一键启用
• ⏸ 断点续跑界面化：长片第 N 步暂停出草稿，方向对了再续跑
• 📹 README 已附演示视频与界面截图
• 同步吸收上游社区 PR Flush Done lines when stdout is a pipe #62/Report progress while the resident video VAE decodes #35/Keep Video VAE RGB output finite for non-finite values #9/ffmpeg: tolerate trailing CSV separator from side-data streams (iPhone .mov) #31，并发布了h3.c 与其他推理栈的对比分析

🔗 https://github.com/skaiy/h3.c-studio

[Henninges]

Hi @skaiy , welcome to the GUI club! 👋

Just a small correction: this isn't actually the first web GUI for h3.c —
I published https://github.com/Henninges/h3-studio on August 16 (4 weeks ago).
It's also bilingual (DE/EN) with Context-IR prompting, but I specialized it
for the music-video workflow: lip-synced video from reference image + audio,
support for 9 images / 3 videos / 3 audio refs, and Context-IR field defaults.

Nice to see the ecosystem growing! Your clip library and chain-last-frame
features look interesting. Would be cool to compare notes on what works
best for users.

[skaiy]

Hi @Henninges — honestly just excited that anyone noticed this and took the time to reply, so thank you for that! 😄

And thanks for the correction — checked your repo's commit history, Aug 16 vs. my Sep 13, so this is fair and square the second GUI, not the first. Ha, guess I'll happily take "#2" then 😂 (going to fix the wording in my README/issue title accordingly).

Went and read through your h3-studio README — the Context-IR fields with smart defaults for empty inputs is a really nice idea, lowers the barrier for the "advanced mode" a lot instead of forcing users to fill in every field. Also love that you specialized hard into the music-video / lip-sync workflow (image + audio → synced video in one pass) with the pose-cue and Ref2VA/FL2VA-can't-mix notes — that's the kind of hard-won prompt-engineering knowledge you only get from actually using the thing a lot, and I don't have an audio-conditioning path in my studio at all yet, so there's real stuff for me to learn from your project.

Funny coincidence too — I'm also on an M-series MacBook Pro with 128GB unified memory, so we're probably fighting the same memory/cache tradeoffs. My side really started from a much simpler place: I just wanted to make it a little easier for people to actually sit down and play with h3.c without wrestling the CLI, so that's what the whole studio/ layer is for.

I honestly have no idea how far mine will end up going either — it's very much "ship what I find useful this week and see" — but I'd genuinely enjoy comparing notes with you, especially on the reference-conditioning UX and anything you've learned about progress-reporting/robustness against real usage. Happy to hop into an issue thread (or wherever's convenient for you) whenever you want to dig into specifics. Welcome to being #1 in the GUI club and looking forward to more people building on antirez's excellent engine 🙌

[Henninges]

Haha, thank YOU for taking the correction so gracefully – "happily take #2"
is exactly the sportsmanship that makes open source great. 😄 And respect for
checking the commit history before answering, that's class.

Seriously: storyboard view, Turbo preset and resumable checkpoints in two
weeks is an impressive shipping pace. Your studio and mine really are two
halves of the same dream – yours makes multi-shot storytelling practical
(FL2VA chaining), mine makes the music-video path practical (Ref2VA with
audio conditioning). Neither can do the other's job today.

Since you mentioned the audio path: I'd genuinely love to share everything
I've learned there, it might save you weeks of weird renders:

• Ref2VA audio constraints (2–15 s, always needs an image/video alongside,
  Ref2VA and FL2VA can't mix in one run)
• prompt semantics: "sings the vocals" vs. "speaks the words" makes or breaks
  lip-sync; speech in non-English languages is currently garbled (model limit)
• the --token-reduction ghosting/audio trap
• pose cues hiding in reference images (back-view pics turn your person around)

And one shared idea I've been circling: a "song storyboard" – cut a track
into ≤15 s segments, render each segment with the same reference images plus
its own audio slice (Ref2VA), then lossless-concat like your storyboard does.
That would combine your chaining/concat engine with my audio workflow and
finally break the 15-second ceiling for music videos. If you're interested,
I'm happy to prototype the segment-cutting + concat side and compare notes
in an issue thread.

Same 128 GB club over here – at least we're the two people who can render
768p without swap anxiety. 😄

Let's keep shipping. And thanks for the kind words about the Context-IR
defaults – they were born from exactly the frustration you describe: nobody
wants to fill five fields just to test a prompt.

[skaiy]

Hi @Henninges — this is genuinely some of the most useful feedback I've gotten on this project, thanks for taking the time to write it all out.

Reacting point by point on the audio notes so you know they didn't just scroll by:

• Ref2VA/FL2VA can't mix — good catch, and slightly embarrassing: my refImages label already says "exclusive w/ anchors" but I never actually wired up a guard. Backend will happily let someone pass both today and presumably eat an error at generation time. I'll add real validation for that, extended to ref_audio too.
• "sings the vocals" vs. "speaks the words", and non-English speech garbling — exactly the kind of thing you only learn by burning GPU-hours. Appreciate you saving me the trial and error.
• --token-reduction fighting with audio — noted, will flag/disable that combo once ref_audio is set.
• Pose cues leaking from reference images — makes sense given how strong identity conditioning is here. Good to know before I chase a "why did they turn around" bug thinking it's my code.

On the song-storyboard idea: I like it, and it maps cleanly onto what already exists — my board/shot/concat plumbing doesn't care what's feeding each shot, so "same reference set + per-segment audio slice" is a plausible new segment type rather than a rewrite. Two things I'd want nailed down before committing to a design:

1. Does identity actually hold across segments with a fixed reference set and no first/last-frame anchor between them (pure Ref2VA doing the work, no FL2VA chaining)?
2. What happens at the splice points once concatenated — natural audio cut points, or do we need a crossfade pass at the video level too?

Happy to open a tracking issue (my repo or yours, whichever you'd rather host it on) once you've got a segment-cutting prototype running. In the meantime I've got --ref-audio wired into my UI now — landed a few hours after your first comment, oddly good timing — so I'll actually run your prompt-semantics and token-reduction warnings against real hardware this week and report back what breaks.

Same 128GB club, cheers 🍻

[Henninges]

@skaiy — now this is how you do an engineering dialogue. Taking each
point and actually wiring it up, not just nodding along. Respect. 🙌

To your two questions on the song storyboard:

1. Identity across segments with fixed Ref2VA, no FL2VA chaining:

Yes — and arguably better than FL2VA chaining. My Take 3 was a 10-second
render with 4 reference angles (front / side / back / endframe), pure
Ref2VA, no first/last-frame anchor at all. Consistency was rock solid
throughout. FL2VA forces the model to start from a locked pixel state,
while Ref2VA lets it choose the best pose freely — which often makes
the result more stable, not less. So the plumbing should work: feed
the same reference set to every segment, no chaining needed.

2. Splice points — natural audio cuts or video crossfade?

Neither, ideally. My plan for the prototype:

• Audio: pre-cut the song with ffmpeg at natural phrase boundaries
  (e.g. between chorus lines), no crossfade — that just muddies things
• Video: FFmpeg concat with -c copy — lossless, frame-accurate,
  no re-encode
• Transition trick: take the last frame of segment N, use it as
  --ref-image for segment N+1 (NOT as --first-frame). That gives
  a smooth visual handoff without the FL2VA lock-in, while the model
  still has freedom to choose its starting pose in each segment.

Happy to host the tracking issue on my repo — I've got the music-video
context already and it feels like the natural home. I'll open it this
week and tag you. First milestone: cut a real song into 3-4 segments,
render each with the same reference set + segment audio, concat, and
see if the identity actually holds end-to-end.

And thank you for actually running my prompt-semantics and token-reduction
notes against real hardware. That's the most useful validation anyone
could give — especially from someone on the same 128 GB club. 🍻

Looking forward to the report.