$npx -y skills add tebjan/vvvv-skills --skill vvvv-patchingExplains vvvv gamma visual programming patterns — dataflow, node connections, regions (ForEach/If/Switch/Repeat/Accumulator), channels for reactive data flow, event handling (Bang/Toggle/FrameDelay/Changed), patch organization, and common anti-patterns (circular dependencies, pol
| 1 | # vvvv Patching Patterns |
| 2 | |
| 3 | ## Dataflow Basics |
| 4 | |
| 5 | - **Left-to-right, top-to-bottom** execution order |
| 6 | - **Links** carry data between pads (input/output connection points) |
| 7 | - **Spreading** — connecting a `Spread<T>` to a single-value input auto-iterates the node |
| 8 | - Every frame, the entire connected graph evaluates; disconnected subgraphs are skipped |
| 9 | |
| 10 | Both visual patches and C# source projects operate in a live environment — edits take effect immediately while the program runs. Patch changes preserve node state; C# code changes trigger a node restart (Dispose → Constructor). You can adjust parameters, add connections, and restructure patches while seeing results in real-time. |
| 11 | |
| 12 | ## When to Patch vs Write C# |
| 13 | |
| 14 | | Patch | Code (C#) | |
| 15 | |---|---| |
| 16 | | Data flow routing, visual connections | Performance-critical algorithms | |
| 17 | | Prototyping and parameter tweaking | Complex state machines | |
| 18 | | UI composition and layout | .NET library interop | |
| 19 | | Simple transformations | Native resource management | |
| 20 | |
| 21 | As a rule: **patch the data flow, code the algorithms**. |
| 22 | |
| 23 | ## Regions |
| 24 | |
| 25 | Regions are visual constructs that control execution flow: |
| 26 | |
| 27 | | Region | Purpose | C# Equivalent | |
| 28 | |---|---|---| |
| 29 | | **ForEach** | Iterate over Spread elements | `foreach` loop | |
| 30 | | **If** | Conditional execution | `if/else` | |
| 31 | | **Switch** | Multi-branch selection | `switch` | |
| 32 | | **Repeat** | Loop N times | `for` loop | |
| 33 | | **Accumulator** | Running aggregation | `Aggregate/Fold` | |
| 34 | |
| 35 | ## Process Nodes in Patches |
| 36 | |
| 37 | Process nodes are the primary way to add state to patches: |
| 38 | - They have a **Create** region (runs once) and an **Update** region (runs each frame) |
| 39 | - Internal state persists between frames |
| 40 | - Can contain sub-patches for complex logic |
| 41 | |
| 42 | ## Channels — Reactive Data Flow |
| 43 | |
| 44 | Channels provide two-way data binding: |
| 45 | - `IChannel<T>` — observable value container |
| 46 | - `.Value` — read or write the current value |
| 47 | - Channels persist state across sessions |
| 48 | - Connect channels between nodes for reactive updates without explicit links |
| 49 | |
| 50 | ## Event Handling |
| 51 | |
| 52 | - **Bang** — a one-frame `true` pulse (trigger) |
| 53 | - **Toggle** — alternates between `true` and `false` |
| 54 | - **FrameDelay** — delays a value by one frame (breaks circular dependencies) |
| 55 | - Use `Changed` node to detect when a value changes between frames |
| 56 | |
| 57 | ## Patch Organization |
| 58 | |
| 59 | ### Naming Conventions |
| 60 | - Use PascalCase for patch names and node names |
| 61 | - Group related operations under a common category |
| 62 | - Use descriptive names that indicate the operation (verb + noun) |
| 63 | |
| 64 | ### Structure |
| 65 | - Keep patches focused — one purpose per patch |
| 66 | - Extract reusable logic into sub-patches |
| 67 | - Use **IOBox** nodes for exposing parameters |
| 68 | - Add **Pad** nodes to create input/output pins on the patch boundary |
| 69 | |
| 70 | ## Common Anti-Patterns |
| 71 | |
| 72 | 1. **Circular dependencies** — use FrameDelay to break cycles |
| 73 | 2. **Too many nodes in one patch** — extract sub-patches |
| 74 | 3. **Polling instead of reacting** — use Channels for reactive updates |
| 75 | 4. **Ignoring Nil** — always handle null/empty Spread inputs gracefully |
| 76 | |
| 77 | For common patterns reference, see [patterns.md](patterns.md). |