Three independently ugly bugs that all fed the same log flood:
* Electron's `WebFrameMain.send` writes every "Render frame was disposed"
to stderr via `console.error`. When the worker fans a second
agent-event past a reloading renderer, we produced thousands of
identical lines and stalled the main loop on stderr I/O. Added a
`mainFrame.detached` guard so the send is short-circuited before
Electron's own catch block fires, and installed a targeted filter in
`suppress-warnings.ts` (now actually imported from the entry point)
so the specific `console.error("Error sending from webFrameMain:"…)`
noise never reaches the terminal. Any other payload still surfaces.
* `dispatchAgentMessage` accepted the human-reader sentinel as a wake
target when an agent replied to `__board__` — `wakeAgentIfPossible`
then called `db.getAgent("__board__")`, threw, and the dispatcher
kept repeating on every send. Strip `HUMAN_SENDER_ID` at
`resolveMessageWakeTargets`, and keep a defense-in-depth guard in the
heartbeat so a stray caller (future automation fan-out) cannot
reintroduce the crash.
* Pi's skills loader rejects any SKILL.md whose frontmatter `name`
diverges from its parent directory. The four bundled `my-writing-style`
copies declared `name: writing-style-skill`, so every install emitted
a warning and dropped the skill. They also lived as orphan gitlinks
(mode 160000 without .gitmodules), and the global `*.md` gitignore
hid every other SKILL.md from version control. Fixed the frontmatter
to match the dir, converted the dangling submodules to plain trees,
and allowlisted `builtin-skills/**/*.md` so a fresh clone carries the
catalogue instead of silently losing it.
2.3 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| parameters | Make a video parametrizable by adding a Zod schema |
|
To make a video parametrizable, a Zod schema can be added to a composition.
First, zod must be installed .
Search the project for lockfiles and run the correct command depending on the package manager:
If package-lock.json is found, use the following command:
npm i zod
If bun.lockb is found, use the following command:
bun i zod
If yarn.lock is found, use the following command:
yarn add zod
If pnpm-lock.yaml is found, use the following command:
pnpm i zod
Then, a Zod schema can be defined alongside the component:
import { z } from "zod";
export const MyCompositionSchema = z.object({
title: z.string(),
});
const MyComponent: React.FC<z.infer<typeof MyCompositionSchema>> = () => {
return (
<div>
<h1>{props.title}</h1>
</div>
);
};
In the root file, the schema can be passed to the composition:
import { Composition } from "remotion";
import { MycComponent, MyCompositionSchema } from "./MyComposition";
export const RemotionRoot = () => {
return (
<Composition
id="MyComposition"
component={MyComponent}
durationInFrames={100}
fps={30}
width={1080}
height={1080}
defaultProps={{ title: "Hello World" }}
schema={MyCompositionSchema}
/>
);
};
Now, the user can edit the parameter visually in the sidebar.
All schemas that are supported by Zod are supported by Remotion.
Remotion requires that the top-level type is a z.object(), because the collection of props of a React component is always an object.
Color picker
For adding a color picker, use zColor() from @remotion/zod-types.
If it is not installed, use the following command:
npx remotion add @remotion/zod-types # If project uses npm
bunx remotion add @remotion/zod-types # If project uses bun
yarn remotion add @remotion/zod-types # If project uses yarn
pnpm exec remotion add @remotion/zod-types # If project uses pnpm
Then import zColor from @remotion/zod-types:
import { zColor } from "@remotion/zod-types";
Then use it in the schema:
export const MyCompositionSchema = z.object({
color: zColor(),
});