cassel/calctext
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

initial commit

Browse Source
This commit is contained in:
C. Cassel
2026-03-16 19:54:53 -04:00
commit bfe0e01254
3341 changed files with 483939 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
_bmad-output/implementation-artifacts/6-9-video-timecodes.md Normal file
View File

@@ -0,0 +1,49 @@
---
epic: 6
story: 6.9
title: "Video Timecodes"
status: draft
---
## Epic 6 — Advanced Math & Functions
**Goal:** Scientific, financial, and power-user math.
### Story 6.9: Video Timecodes
As a **CalcPad user**,
I want to perform arithmetic on video timecodes in HH:MM:SS:FF format with support for common frame rates,
So that I can calculate durations and offsets for video editing workflows.
**Acceptance Criteria:**
**Given** the user writes `01:30:00:00 + 00:15:30:00` (at the default frame rate)
**When** the engine evaluates
**Then** the result is `01:45:30:00`
**Given** the user writes `01:00:00:00 - 00:30:00:00`
**When** the engine evaluates
**Then** the result is `00:30:00:00`
**Given** the frame rate is set to 24 fps and the user writes `00:00:00:23 + 00:00:00:01`
**When** the engine evaluates
**Then** the result is `00:00:01:00` (frame 23 + 1 frame = 1 second at 24 fps)
**Given** the frame rate is set to 29.97 fps (drop-frame)
**When** the user writes `00:00:59:29 + 00:00:00:01`
**Then** the result correctly accounts for drop-frame timecode rules (frame numbers 0 and 1 are skipped at certain minute boundaries)
**Given** the user writes a timecode with a frame value exceeding the frame rate (e.g., `00:00:00:30` at 24 fps)
**When** the engine evaluates
**Then** an error is displayed indicating the frame value is out of range for the current frame rate
**Given** the user configures the frame rate to one of the supported values: 23.976, 24, 25, 29.97, 30, 60 fps
**When** subsequent timecode arithmetic is performed
**Then** the engine uses the configured frame rate for all carry and overflow calculations
**Given** the user writes a subtraction that would result in a negative timecode (e.g., `00:00:10:00 - 00:01:00:00`)
**When** the engine evaluates
**Then** the result is displayed as a negative timecode or an error is shown, depending on the design decision (clearly documented)
**Given** the user writes `01:30:00:00` without any arithmetic
**When** the engine evaluates
**Then** the timecode is recognized and displayed as-is in HH:MM:SS:FF format (parsed but not altered)