vvvv gamma Fundamentals
What Is vvvv gamma
vvvv gamma is a visual programming environment for .NET 8. It combines node-based patching with C# code generation, targeting Stride (3D engine) and .NET APIs. Programs are built by connecting nodes with links in a visual editor.
vvvv is a live programming environment — programs run continuously while you build them. Both visual patch edits and C# code changes take effect immediately without restarting. vvvv compiles C# source files itself via Roslyn into in-memory assemblies on every save.
Document Structure
.vl files — vvvv gamma documents (XML-based, version controlled)
- Each document contains Patches (visual programs) and Definitions (types, operations)
- Documents can reference NuGet packages and other
.vl files
- The Patch Explorer shows the document's type hierarchy
Execution Model
- Frame-based evaluation — the mainloop evaluates the entire graph every frame (~60 FPS)
- Data flows left-to-right, top-to-bottom through links between nodes
- Process nodes maintain state between frames (constructor → Update loop → Dispose)
- Operation nodes are pure functions evaluated each frame
- vvvv evaluates all connected nodes, skips disconnected subgraphs
Live Compilation Model
vvvv runs your program continuously while you edit it. There is no edit-compile-run cycle for patches and shaders. For C#, live reload depends on how the code is referenced.
Patch Changes
- Edits to visual patches apply immediately
- Node state (instance fields) is preserved across edits
- New nodes and links become active on the next frame
Shader Changes
.sdsl shader files always live-reload when saved
- vvvv recompiles shaders in the background and swaps them in the running program
C# — Two Workflows
C# code can be integrated via source project reference or pre-compiled binary. The choice depends on project size and development phase.
Source project reference (live reload):
When a .vl document references a .csproj source project, vvvv compiles .cs files itself via Roslyn into in-memory assemblies. No dotnet build or external toolchain is involved.
- On .cs file save, vvvv detects the change and recompiles in the background
- Status indicator: gray = building symbols, orange = emitting C#
- On successful compilation, affected nodes restart their lifecycle:
Dispose() called on old instance
- New constructor runs (with fresh
NodeContext)
Update() resumes on the next frame
- Static fields reset on reload — the entire in-memory assembly is replaced
- On compilation error, the program continues running with the last valid code
Binary reference (no live reload):
When a .vl document references a pre-compiled DLL or NuGet package, the assembly is loaded once at startup. To pick up changes, you must rebuild the DLL externally (e.g., dotnet build) and restart vvvv. This workflow is common for larger projects and stable libraries where live reload is not needed.
Node Categories
Process Nodes
- Have Create (constructor), Update (per-frame), and Dispose lifecycle
- Written in C# with
[ProcessNode] attribute
- Maintain internal state between frames
- Use change detection to avoid redundant work
Operation Nodes
- Pure functions: same input always produces same output
- Written as static C# methods (auto-discovered by vvvv)
- No state between frames
- No
[ProcessNode] attribute needed
Adaptive Nodes
- Nodes that adapt their implementation based on connected input types
- Example:
+ works with int, float, Vector3, string, etc.
- Resolved at link-time, not runtime
Pins, Pads, and Links
- Pins — inputs and outputs on nodes and regions
- Pads — visual nodes for reading/writing Properties inside operation patches; all pads with the same name refer to the same property
- Links — connections between pins that define data flow and execution order
- Spreading — when a
Spread<T> connects to a single-value input, the node auto-iterates
When to Patch vs Write C#
| Use Patching |
Use C# Code |
| Prototyping, data flow |
Custom nodes, performance-critical code |
| Visual connections, UI composition |
Complex algorithms |
| Real-time parameter tweaking |
.NET library interop |
| Dataflow routing and spreading |
Native/unmanaged resource management |
Channels — Reactive Data Flow
IChannel<T> — observable value container
IChannel<T>.Value — read/write the current value
Channel.IsValid() — check if connected
- Channels persist state across sessions
- Enable two-way data binding between UI and patch
For C# channel integration patterns (IChannelHub, PublicChannelHelper, [CanBePublished]), see vvvv-channels.
Key Data Types
| Type |
C# Equivalent |
Usage |
Spread<T> |
ImmutableArray<T> |
vvvv's immutable collection |
SpreadBuilder<T> |
ImmutableArray<T>.Builder |
Build spreads efficiently |
| Float32, Int32, etc. |
float, int |
Primitives |
Vector2/3/4 |
Stride.Core.Mathematics |
Spatial math |
Color4 |
Stride.Core.Mathematics |
RGBA color |
File Types
| Extension |
Purpose |
.vl |
vvvv gamma documents (XML-based) |
.sdsl |
Stride shader files (SDSL language) |
.cs |
C# source files for custom nodes |
.csproj |
.NET project files |
.nuspec |
NuGet package spec |
Ecosystem Overview
vvvv's functionality extends through NuGet packages that bundle .vl documents, C# nodes, and shaders.
| Domain |
Key Packages |
| 3D Rendering |
VL.Stride (Stride engine), VL.Fuse (GPU visual programming) |
| 2D Rendering |
VL.Skia, ImGui, Avalonia, CEF/HTML |
| Hardware I/O |
DMX/Art-Net, ILDA lasers, depth cameras (Azure Kinect, ZED), robotics (KUKA, Spot), Ultraleap, LiDAR |
| Networking |
OSC, MIDI, MQTT, Redis, WebSocket, HTTP, TCP/UDP, ZeroMQ, Modbus, Ableton Link |
| Computer Vision |
OpenCV, MediaPipe, YOLO (v8–v11), ONNX Runtime |
| Audio |
NAudio, VST hosting, SuperCollider bridge |
| General .NET |
Any of 100,000+ standard NuGet packages via .csproj reference |
To add a package: reference it in your .vl document's Dependencies, or add a <PackageReference> to your .csproj. See vvvv-dotnet for .csproj details.
AppHost & Runtime Detection
// Detect if running as exported .exe vs editor
bool isExported = nodeContext.AppHost.IsExported;
// Register per-app singleton services
nodeContext.AppHost.Services.RegisterService(myService);
For detailed reference, see reference.md.
1---2name: vvvv-fundamentals3description: Explains vvvv gamma core concepts — data types, frame-based execution model, pins, pads, links, node browser, live compilation (source project vs binary reference workflows), .vl document structure, file types (.vl/.sdsl/.cs/.csproj), ecosystem overview, and AppHost runtime detection. Use when the user asks about vvvv basics, how vvvv works, the live reload model, when to patch vs code, or needs an overview of the visual programming environment.4license: CC-BY-SA-4.05---6
7# vvvv gamma Fundamentals
8
9## What Is vvvv gamma
10
11vvvv gamma is a visual programming environment for .NET 8. It combines node-based patching with C# code generation, targeting Stride (3D engine) and .NET APIs. Programs are built by connecting nodes with links in a visual editor.
12
13vvvv is a live programming environment — programs run continuously while you build them. Both visual patch edits and C# code changes take effect immediately without restarting. vvvv compiles C# source files itself via Roslyn into in-memory assemblies on every save.
14
15## Document Structure
16
17- **`.vl` files** — vvvv gamma documents (XML-based, version controlled)
18- Each document contains **Patches** (visual programs) and **Definitions** (types, operations)
19- Documents can reference NuGet packages and other `.vl` files
20- The **Patch Explorer** shows the document's type hierarchy
21
22## Execution Model
23
24- **Frame-based evaluation** — the mainloop evaluates the entire graph every frame (~60 FPS)
25- **Data flows left-to-right, top-to-bottom** through links between nodes
26- **Process nodes** maintain state between frames (constructor → Update loop → Dispose)
27- **Operation nodes** are pure functions evaluated each frame
28- vvvv evaluates all connected nodes, skips disconnected subgraphs
29
30## Live Compilation Model
31
32vvvv runs your program continuously while you edit it. There is no edit-compile-run cycle for patches and shaders. For C#, live reload depends on how the code is referenced.
33
34### Patch Changes
35
36- Edits to visual patches apply immediately
37- Node state (instance fields) is preserved across edits
38- New nodes and links become active on the next frame
39
40### Shader Changes
41
42- `.sdsl` shader files always live-reload when saved
43- vvvv recompiles shaders in the background and swaps them in the running program
44
45### C# — Two Workflows
46
47C# code can be integrated via source project reference or pre-compiled binary. The choice depends on project size and development phase.
48
49**Source project reference** (live reload):
50
51When a .vl document references a .csproj source project, vvvv compiles .cs files itself via Roslyn into in-memory assemblies. No `dotnet build` or external toolchain is involved.
52
53- On .cs file save, vvvv detects the change and recompiles in the background
54- Status indicator: gray = building symbols, orange = emitting C#
55- On successful compilation, affected nodes restart their lifecycle:
56 1. `Dispose()` called on old instance
57 2. New constructor runs (with fresh `NodeContext`)
58 3. `Update()` resumes on the next frame
59- Static fields reset on reload — the entire in-memory assembly is replaced
60- On compilation error, the program continues running with the last valid code
61
62**Binary reference** (no live reload):
63
64When a .vl document references a pre-compiled DLL or NuGet package, the assembly is loaded once at startup. To pick up changes, you must rebuild the DLL externally (e.g., `dotnet build`) and restart vvvv. This workflow is common for larger projects and stable libraries where live reload is not needed.
65
66## Node Categories
67
68### Process Nodes
69- Have Create (constructor), Update (per-frame), and Dispose lifecycle
70- Written in C# with `[ProcessNode]` attribute
71- Maintain internal state between frames
72- Use change detection to avoid redundant work
73
74### Operation Nodes
75- Pure functions: same input always produces same output
76- Written as static C# methods (auto-discovered by vvvv)
77- No state between frames
78- No `[ProcessNode]` attribute needed
79
80### Adaptive Nodes
81- Nodes that adapt their implementation based on connected input types
82- Example: `+` works with int, float, Vector3, string, etc.
83- Resolved at link-time, not runtime
84
85## Pins, Pads, and Links
86
87- **Pins** — inputs and outputs on nodes and regions
88- **Pads** — visual nodes for reading/writing Properties inside operation patches; all pads with the same name refer to the same property
89- **Links** — connections between pins that define data flow and execution order
90- **Spreading** — when a `Spread<T>` connects to a single-value input, the node auto-iterates
91
92## When to Patch vs Write C#
93
94| Use Patching | Use C# Code |
95|---|---|
96| Prototyping, data flow | Custom nodes, performance-critical code |
97| Visual connections, UI composition | Complex algorithms |
98| Real-time parameter tweaking | .NET library interop |
99| Dataflow routing and spreading | Native/unmanaged resource management |
100
101## Channels — Reactive Data Flow
102
103- `IChannel<T>` — observable value container
104- `IChannel<T>.Value` — read/write the current value
105- `Channel.IsValid()` — check if connected
106- Channels persist state across sessions
107- Enable two-way data binding between UI and patch
108
109For C# channel integration patterns (IChannelHub, PublicChannelHelper, [CanBePublished]), see vvvv-channels.
110
111## Key Data Types
112
113| Type | C# Equivalent | Usage |
114|---|---|---|
115| `Spread<T>` | `ImmutableArray<T>` | vvvv's immutable collection |
116| `SpreadBuilder<T>` | `ImmutableArray<T>.Builder` | Build spreads efficiently |
117| Float32, Int32, etc. | `float`, `int` | Primitives |
118| `Vector2/3/4` | `Stride.Core.Mathematics` | Spatial math |
119| `Color4` | `Stride.Core.Mathematics` | RGBA color |
120
121## File Types
122
123| Extension | Purpose |
124|---|---|
125| `.vl` | vvvv gamma documents (XML-based) |
126| `.sdsl` | Stride shader files (SDSL language) |
127| `.cs` | C# source files for custom nodes |
128| `.csproj` | .NET project files |
129| `.nuspec` | NuGet package spec |
130
131## Ecosystem Overview
132
133vvvv's functionality extends through NuGet packages that bundle .vl documents, C# nodes, and shaders.
134
135| Domain | Key Packages |
136|---|---|
137| 3D Rendering | VL.Stride (Stride engine), VL.Fuse (GPU visual programming) |
138| 2D Rendering | VL.Skia, ImGui, Avalonia, CEF/HTML |
139| Hardware I/O | DMX/Art-Net, ILDA lasers, depth cameras (Azure Kinect, ZED), robotics (KUKA, Spot), Ultraleap, LiDAR |
140| Networking | OSC, MIDI, MQTT, Redis, WebSocket, HTTP, TCP/UDP, ZeroMQ, Modbus, Ableton Link |
141| Computer Vision | OpenCV, MediaPipe, YOLO (v8–v11), ONNX Runtime |
142| Audio | NAudio, VST hosting, SuperCollider bridge |
143| General .NET | Any of 100,000+ standard NuGet packages via .csproj reference |
144
145To add a package: reference it in your `.vl` document's Dependencies, or add a `<PackageReference>` to your `.csproj`. See vvvv-dotnet for .csproj details.
146
147## AppHost & Runtime Detection
148
149```csharp
150// Detect if running as exported .exe vs editor
151bool isExported = nodeContext.AppHost.IsExported;
152
153// Register per-app singleton services
154nodeContext.AppHost.Services.RegisterService(myService);
155```
156
157For detailed reference, see [reference.md](reference.md).