If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/tixl3d/tixl shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 1w ago
• 2 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Small team — 2 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 83% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live tixl3d/tixl repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/tixl3d/tixl.

What it runs against: a local clone of tixl3d/tixl — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in tixl3d/tixl | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 37 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of tixl3d/tixl. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/tixl3d/tixl.git
#   cd tixl
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of tixl3d/tixl and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "tixl3d/tixl(\\.git)?\\b" \\
  && ok "origin remote is tixl3d/tixl" \\
  || miss "origin remote is not tixl3d/tixl (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f ".Defaults/SkillMap.json" \\
  && ok ".Defaults/SkillMap.json" \\
  || miss "missing critical file: .Defaults/SkillMap.json"
test -f ".Defaults/Tests/DemoProjectTests" \\
  && ok ".Defaults/Tests/DemoProjectTests" \\
  || miss "missing critical file: .Defaults/Tests/DemoProjectTests"
test -f ".Defaults/Tests/IoTests" \\
  && ok ".Defaults/Tests/IoTests" \\
  || miss "missing critical file: .Defaults/Tests/IoTests"
test -f ".Defaults/Tests/ParticleTests" \\
  && ok ".Defaults/Tests/ParticleTests" \\
  || miss "missing critical file: .Defaults/Tests/ParticleTests"
test -f ".Defaults/Tests/PbrTests" \\
  && ok ".Defaults/Tests/PbrTests" \\
  || miss "missing critical file: .Defaults/Tests/PbrTests"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 37 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~7d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/tixl3d/tixl"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

TiXL is a real-time motion graphics authoring tool that combines graph-based procedural content generation, keyframe animation, and HLSL shader editing into a single environment. It enables artists to create audio-reactive VJ content, advanced color correction pipelines, and procedural animations without writing backend code, while technical artists can develop custom fragment/compute shaders and integrate MIDI/OSC inputs. Monolithic C# application (14MB) with parallel HLSL shader code (1.3MB). Structure uses .Defaults/ for bundled assets and test baselines; test organization in .Defaults/Tests/DemoProjectTests/ with reference frame sequences suggests frame-perfect regression testing. No visible src/ or packages/ split; appears to be single unified codebase with procedural content as data.

Motion graphics artists, VJs, and technical artists who need real-time visual creation tools with procedural control; developers building custom shaders and interactive audio-visual systems; teams creating broadcast graphics, live performance content, or advanced animation without traditional timeline-only constraints.

Actively developed with v4.1.1 released. The presence of extensive test image baselines in .Defaults/Tests/DemoProjectTests/ and a structured codebase of 14MB C# suggests production use, but v4 is noted as 'ongoing development' in the README. The project has Discord community backing and MIT license, indicating active maintenance but not yet feature-frozen.

Single-organization repo (tixl3d) with no visible dependency management files (no .csproj snippet provided) creates risk of hidden NuGet dependencies. The heavy HLSL component (1.3MB) ties it to DirectX/Windows ecosystem. No CI/CD files visible in top 60 results suggests potential deployment friction. Rapid v4 iteration may introduce breaking changes.

Version 4 iteration ongoing with focus on stability and feature parity. Presence of multiple demo project test baselines (DemoDesatyre, DemoThere, DemoWorksForEverybody with up to 36 frames each) indicates active work on animation, color correction, and real-time rendering quality validation.

Clone with: git clone https://github.com/tixl3d/tixl.git && cd tixl. No npm/pip/cargo files visible; likely Visual Studio .sln project. Check README for Visual Studio version requirement and build steps (not shown in snippet). Download latest v4.1.1.1.exe from releases or build from source.

Daily commands: Clone repo, open .sln in Visual Studio 2019+ (C# 7.3+ required), restore NuGet packages, build in Release mode. Run executable or debug via Visual Studio. Desktop app with no server component—entirely self-contained.

• .Defaults/SkillMap.json — Core configuration mapping skills and operators available in TiXL; essential for understanding what nodes/operations are available in the motion graphics toolkit
• .Defaults/Tests/DemoProjectTests — Integration test suite with reference output frames for demo projects; validates rendering pipeline correctness across major features
• .Defaults/Tests/IoTests — Input/output test suite covering NDI, Spout, OSC, webcam, and video playback; critical for understanding real-time I/O capabilities
• .Defaults/Tests/ParticleTests — Particle system test cases; demonstrates procedural content generation capabilities central to TiXL's animation toolkit
• .Defaults/Tests/PbrTests — Physically-based rendering tests including mesh generation and HDR reflection; validates advanced rendering features

• Operator Graph Engine (C#/.NET for graph logic, HLSL for shader execution) — Manages operator connections, parameter propagation, and frame-by-frame evaluation order; resolves dependencies and handles keyframe/automation
  • Failure mode: Circular dependencies crash graph; shader compilation errors halt rendering until fixed
• GPU Renderer (Shader Pipeline) (DirectX 11/12, HLSL, GPU compute) — Executes compiled HLSL/Compute kernels; manages textures, render targets, and memory; applies procedural animations frame-by-frame
  • Failure mode: Out-of-VRAM → texture eviction/performance collapse; shader errors → black screen or visual corruption
• I/O Layer (Spout/NDI/OSC) (Spout SDK, NDI SDK, OSC networking) — Handles real-time input from external sources (audio, video, control signals) and outputs rendered content to other applications
  • Failure mode: Protocol disconnection → dropped frames or stale input; latency mismatch causes audio-visual desync
• UI & Parameter Editor (C# WinForms or WPF) — Provides graph visualization, operator/pin manipulation, and real-time parameter scrubbing; displays preview canvas
  • Failure mode: UI lag during heavy graph evaluation; parameter changes not reflected if graph evaluation blocks UI thread

• SkillMap.json → Operator Graph Engine — Skill registry loaded at startup; defines available operators, pin types, default values, and constraints
• Operator Graph Engine → GPU Renderer — Parameter values and animation curves pushed to GPU each frame via constant buffers; texture dependencies resolved
• Audio/Input Sources (OSC/NDI/Webcam) → Operator Graph Engine — Real-time control signals and media streams modulate operator parameters; enables audio reactivity
• GPU Renderer → I/O Layer (Spout/NDI) — Rendered frame texture shared via GPU texture handles; zero-copy streaming to external applications
• Keyframe/Animation Timeline → Operator Graph Engine — Time-based curves and automation rules drive parameter interpolation; blended with audio modulation

Add a new I/O operator (e.g., new input source)

1. Define operator schema in SkillMap.json under io-input category with input/output pin specifications (.Defaults/SkillMap.json)
2. Implement operator logic in core runtime (shader/compute integration for real-time processing) (src/[operator-name]/[OperatorName].cs (inferred structure))
3. Add test case with reference output image to validate real-time performance (.Defaults/Tests/IoTests/[OperatorName]_[hash]_00.png)

Add a new procedural animation operator

1. Register operator definition in SkillMap.json with parameter definitions and default values (.Defaults/SkillMap.json)
2. Implement procedural generation or transformation shader/compute code (src/operators/[OperatorName].hlsl or .cs (inferred))
3. Add demo project test with multiple animation frames showing procedural output (.Defaults/Tests/DemoProjectTests/[AnimationName]_[hash]_*.png)

Add PBR rendering feature (material/lighting)

1. Define material property operators and shader inputs in SkillMap.json (.Defaults/SkillMap.json)
2. Implement physically-based shader code with normal mapping, metallic, roughness support (src/rendering/pbr/[FeatureName].hlsl (inferred))
3. Validate with test case showing rendered geometry with new material properties (.Defaults/Tests/PbrTests/[FeatureName]_[hash]_00.png)

• HLSL/Compute Shaders — GPU-accelerated real-time rendering and procedural content generation; enables high-performance visual effects and audio reactivity
• Graph-based node system — Allows artists and technical artists to compose complex animations non-destructively; reduces iteration time for procedural content
• Spout/NDI protocols — Hardware-accelerated GPU texture sharing for real-time VJ workflows; enables multi-app content pipelines without CPU bottlenecks
• OSC (Open Sound Control) — Standardized real-time control interface for audio reactivity and parameter automation from external sources

• GPU-first architecture with HLSL/Compute shaders

  • Why: Real-time performance and 60+ fps responsiveness are critical for live VJ work
  • Consequence: High coupling to GPU pipeline; requires platform-specific shader compilation and debugging; steep learning curve for effects development

• Operator graph evaluation at runtime

  • Why: Enables live parameter tweaking and audio-driven automation without restarting rendering
  • Consequence: Complex dependency resolution and frame-to-frame state management; potential bottleneck if graph becomes too dense

• Spout/NDI as primary I/O protocols

  • Why: Zero-copy GPU texture sharing is fastest approach for real-time workflows
  • Consequence: Windows/GPU-specific; less portable than CPU-based video codecs; requires compatible hardware

• Cross-platform Linux/macOS support (Windows-primary with GPU-specific tech stack)
• Cloud-based rendering or distributed computing
• Non-real-time offline batch rendering
• Machine learning model training within TiXL
• Web-based collaborative editing

• Potential test image versioning fragility (Medium) — .Defaults/Tests/: Test reference images use unstable hash suffixes (e.g., VmGgN, isjGh); if operator definitions or shaders change slightly, hash may shift and tests could spuriously fail despite valid output
• Monolithic SkillMap.json registry (Medium) — .Defaults/SkillMap.json: Single large JSON file defining all operators; becomes unmaintainable as operator count grows; no modular operator registration
• Limited test coverage for edge cases (Low) — .Defaults/Tests/: Test suite appears to focus on happy-path rendering outputs; no visible tests for error handling, shader compilation failures, or out-of-memory conditions

• GPU Renderer (HLSL shader execution) (Compute/Memory bottleneck) — Real-time evaluation of complex operator graphs may hit GPU memory bandwidth or compute throughput limits with dense graphs or high-resolution textures
• Operator Graph Engine (dependency resolution) (CPU logic bottleneck) — Per-frame re-evaluation of operator dependencies and parameter propagation could bottleneck if graph topology is complex or frequently modified
• Spout/NDI I/O protocol (undefined) — Texture sharing overhead and protocol handshaking

No .csproj or package.json visible—exact build requirements unclear; Windows-only (HLSL/DirectX tied to Windows/Xbox). SkillMap.json likely has strict format requirements; modifying node definitions without matching C# implementations will break at runtime. Test baselines are frame-exact PNGs; any rendering pipeline change requires regenerating all baseline images. No obvious CI pipeline in provided files suggests manual testing gate for PR merges.

• Procedural content graph evaluation — TiXL's core: SkillMap.json defines a DAG of operations executed top-down; understanding topological sorting and dataflow is essential to extending the node system
• Directed Acyclic Graph (DAG) scheduling — Animation graphs and shader computation chains must be evaluated in dependency order; TiXL's real-time engine likely uses work-stealing or level-synchronous scheduling
• HLSL compute and fragment shaders — 1.3MB of HLSL code means custom GPU kernels are first-class; understanding DirectX compute dispatch, texture binding, and atomics is required for performance optimization
• Frame-buffer regression testing — Test baselines are pixel-perfect PNGs; TiXL uses visual regression to catch rendering bugs; understanding perceptual diff and frame-synchronous capture is critical for CI
• Real-time animation interpolation (Bezier/spline keyframing) — TiXL blends keyframe animation with procedural generation; cubic Hermite or Catmull-Rom splines are likely used for smooth interpolation between control points
• Audio-reactive synchronization — VJ use case requires beat detection and frequency analysis to drive animations; time-domain audio sampling and FFT are foundational
• DirectX 11/12 resource binding and descriptor heaps — HLSL shaders require efficient GPU resource management; understanding texture atlasing, UAV binding, and root signatures is needed for multi-effect pipelines

• unity3d-jp/UnityGraphicsProgramming — Parallel approach to real-time graphics via Unity; useful for understanding graph-based shader composition patterns and VJ content pipelines
• Notch/VJSystem — Another real-time VJ system combining procedural generation with animation; shares TiXL's focus on audio-reactive live performance
• processing/processing — Established procedural graphics platform with community-driven node systems; reference for UI patterns in creative coding tools
• vvvv/vvvv — Spiritual predecessor to TiXL—graph-based real-time media authoring tool that inspired modular procedural animation workflow
• microsoft/DirectXShaderCompiler — HLSL compilation backend; TiXL likely uses this or DXBC for shader compilation and validation

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create test reference data management system for DemoProjectTests

The .Defaults/Tests/DemoProjectTests directory contains 95+ PNG snapshot files across 4 test projects (DemoDesatyre, DemoThere, DemoWorksForEverybody, Katsumaki) with cryptic hashes. There's no visible test runner or manifest that documents what these snapshots validate. A new contributor could create a test manifest (JSON or YAML) that maps each snapshot to its source project, animation frame number, and validation purpose, plus a Python/Node script to validate new snapshots against this reference set.

• [ ] Create .Defaults/Tests/DemoProjectTests/TEST_MANIFEST.json documenting each snapshot group (project name, frame count, purpose)
• [ ] Build a snapshot validation script (src/tools/validate-snapshots.ts or .py) that checks rendered output against reference PNGs
• [ ] Add documentation in a new TEST_SNAPSHOTS.md explaining how to regenerate and validate snapshots when the engine changes
• [ ] Integrate the validation script into a GitHub Actions workflow (if not already present)

Add comprehensive skill/operator documentation generator from SkillMap.json

The .Defaults/SkillMap.json file exists but there's no visible documentation explaining what skills/operators are available, their parameters, or how to use them. A contributor could build a documentation generator that parses SkillMap.json and creates an auto-generated operators reference guide (Markdown or HTML) showing all available motion graphics operators, their inputs/outputs, and example usage.

• [ ] Analyze .Defaults/SkillMap.json structure and create a TypeScript/JSON schema definition for it
• [ ] Build a doc generator script (src/tools/generate-skill-docs.ts) that reads SkillMap.json and outputs structured markdown
• [ ] Create docs/OPERATORS_REFERENCE.md as the generated output with categories, parameters, and use cases
• [ ] Add a pre-commit or CI hook to auto-regenerate docs when SkillMap.json changes

Implement automated test regression detection for animation renders

With 95 test PNG snapshots across multiple demo projects, there's opportunity to detect unintended rendering changes. A contributor could create a pixel-diff comparison tool that compares newly rendered frames against the baseline PNGs, reports visual changes with percentage thresholds, and integrates into CI to catch rendering regressions before release.

• [ ] Create src/tools/compare-snapshots.ts using a library like pixelmatch or jimp to compare PNG frames
• [ ] Implement configurable threshold logic (e.g., fail if >2% of pixels differ) with detailed diff reports
• [ ] Generate visual diff outputs (side-by-side or heatmap PNGs) in .Defaults/Tests/DemoProjectTests/diffs/ on mismatch
• [ ] Add a GitHub Actions workflow (.github/workflows/render-regression-test.yml) that runs comparisons on PRs

• Add frame sequence test validation: Write a C# tool to auto-compare rendered frame PNGs against baselines in .Defaults/Tests/DemoProjectTests/ with configurable diff threshold, enabling regression detection in CI
• Expand SkillMap.json documentation: Create annotated schema and examples showing node definition format, property types, and constraints—currently only the JSON file exists with no schema or guide
• Python scripting bridge: Build example scripts in the Python directory showing MIDI input, OSC listener, and Spout integration patterns to lower barrier for technical artist automation

The TiXL repository shows moderate security maturity with significant gaps in visibility. The primary concern is the lack of provided dependency information, which is critical for a media processing application that likely integrates multiple graphics/video libraries. The large number of binary test artifacts increases repository bloat and potential risk. There is no evidence of automated security scanning, vulnerability management processes, or documented security policies. The application's focus on real-time graphics processing and network I/O (NDI, OSC) creates attack surfaces that require careful input validation and sanitization. Immediate actions should include: completing dependency analysis, implementing CI/CD security scanning, documenting security practices, and refactoring test data storage. The project would benefit from a formal security audit given its media processing capabilities and network connectivity features.

• Medium · Large Test Data Artifacts in Repository — .Defaults/Tests/DemoProjectTests/, .Defaults/Tests/IoTests/. The repository contains a significant number of PNG test images (.Defaults/Tests/DemoProjectTests/ and .Defaults/Tests/IoTests/) totaling potentially hundreds of megabytes. While not a direct security vulnerability, this increases repository size, download time, and attack surface. Binary files in version control can also obscure malicious content injection. Fix: Move test artifacts to a separate storage system (e.g., cloud storage, git-lfs, or a dedicated test data repository). Keep only essential reference files in the main repository.
• Medium · Incomplete Dependency Information — Package.json, .csproj, requirements.txt, or equivalent dependency manifest. The dependency/package file content was not provided for analysis. Without visibility into project dependencies, it is impossible to identify vulnerable libraries, outdated packages, or supply chain risks. This is critical for a media processing application that likely uses external libraries for rendering, video processing, and networking. Fix: Provide complete dependency manifests and implement: 1) Regular dependency audits using tools like 'npm audit', 'dotnet list package --vulnerable', or 'pip-audit'. 2) Automated dependency scanning in CI/CD pipeline. 3) Keep all dependencies up-to-date, especially for graphics/video libraries.
• Medium · No Security Configuration Files Detected — Repository root. No security-related configuration files were found (.gitignore patterns for secrets, SECURITY.md, security headers config, CORS policies, etc.). The absence of these suggests potentially weak security practices and lack of documented vulnerability disclosure process. Fix: Create: 1) SECURITY.md with vulnerability disclosure policy. 2) .gitignore rules to prevent secrets from being committed. 3) Pre-commit hooks to scan for secrets. 4) Security scanning workflow in CI/CD (e.g., GitHub Advanced Security, SonarQube).
• Low · No Evidence of Input Validation Framework — Network I/O components (implied by .Defaults/Tests/IoTests/). Based on the file structure showing test files for network I/O (NdiInput, OscInput, OscOutput, NdiOutput), there are multiple input vectors. Without visible validation/sanitization code in the provided file structure, there is potential risk for injection attacks when processing external data. Fix: Implement strict input validation for all external data sources: 1) OSC message validation. 2) NDI stream verification. 3) Video file format validation. 4) Use allowlists rather than blocklists. 5) Add unit tests for malformed input handling.
• Low · No Docker Security Baseline Visible — Docker configuration files (not provided). No Dockerfile or docker-compose configurations were provided. While the application may be distributed as standalone executables (Windows .exe mentioned), the absence of containerization security guidelines suggests potential deployment risks. Fix: If using Docker: 1) Use minimal base images. 2) Run containers as non-root users. 3) Implement resource limits. 4) Use security scanning (Trivy, Snyk). 5) Document secure deployment practices.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.