VJ UNION: vdmo

PCHI 2.0: When Mathematics Conducts the Live Show

vdmo — Thu, 24 Sep 2026 17:40:40 +0000

For years, the live audiovisual stack has been a beautiful, fragile spiderweb. Resolume driving layers and clips. TouchDesigner generating procedural geometry or reactive particles. Ableton holding the pulse. Unreal Engine handling high-fidelity 3D. Tracking systems, lighting desks, custom OSC maps, and increasingly, generative AI agents whispering suggestions into the mix.

It works—until it doesn’t. A silent desync, a parameter that drifts, a generative agent that “creatively” pushes opacity past 1.0 or sends a tentacle into the audience’s face. Convention holds the system together. When something breaks, debugging becomes archaeology.

PCHI 2.0 (Peachy) proposes something different: move from convention-based to mathematics-based scene management. One shared language. Verified state. Equilibrium by design.

One Language for the Whole Creative Stack

PCHI is an open protocol for scene state. It standardizes messages for objects, control parameters, musical context, artist tracking, and more. Every message carries its own mathematical signature—PIR invariants (Prime Integer Relations)—rooted in the Prouhet–Thue–Morse sequence.

These aren’t decorative checksums. They encode equilibrium checks (a residual that should sit near (10^{-12})), coherence gaps that surface drift, and curvature signatures that describe the smoothness of transitions. The Conductor (PrimeSwarm Engine, written in Rust) receives proposed updates, verifies the invariants, applies Only-Lang governance rules, and only then broadcasts a coherent, validated state to every connected tool via UDP, WebSocket, or TCP.

Many tools. One truth.

Existing bridges already make this practical:

A Python OSC bridge for Resolume Arena that calculates PIR values on the fly.
A TouchDesigner Python CHOP that surfaces scene objects, BPM/beat/kick/snare, and equilibrium status as channels.
A Max for Live device that watches Ableton’s musical state and injects verified musical context.
Schemas in both human-readable JSON and high-performance FlatBuffers.

The result feels less like duct-taping software together and more like placing every tool inside the same mathematical spacetime.

Why Math People Should Care

The Prouhet–Thue–Morse sequence is one of those quietly profound objects: aperiodic, cube-free, deeply linked to automatic sequences, combinatorics on words, and even quantum information ideas. PCHI embeds a practical use of its sign sequence into the real-time critical path of a live performance system.

Equilibrium is no longer “the operator is watching the scopes.” It is a computed residual. Disequilibrium is caught before the frame is rendered. For anyone who has ever found beauty in invariant theory, discrepancy, or the way discrete mathematics can enforce continuous harmony, this is a concrete aesthetic application.

It also opens a clean interface for safe generative AI. Only-Lang is a simple rule DSL that lets you declare hard mathematical boundaries:

if kraken_tentacle.wobbliness > 0.8
then
    kraken_tentacle.wobbliness = 0.8
end

Creative freedom remains. Clear boundaries are enforced at the protocol level rather than hoped for in prompt engineering.

Why AV Creatives Should Care

Live shows are increasingly multi-tool and multi-agent. The cost of silent failure rises with every additional node. PCHI does not replace your favorite software; it gives them a shared, verifiable nervous system.

You keep working in the environments you already love. The Conductor becomes the single source of truth. AI agents can propose changes without the risk of catastrophic divergence. Musical context from Ableton can drive visuals with mathematical confidence that the systems are still in phase. Tracking data and scene transforms stay coherent across Resolume, TouchDesigner, and Unreal.

In short: creativity without the chaos of unmanaged state.

The Larger Gesture

There is a long tradition of artists who treated mathematics not as constraint but as material—Escher’s tessellations, the geometric rigor of the Renaissance, contemporary practices that treat code and invariants as sculptural medium. PCHI sits in that lineage while remaining ruthlessly practical for the people who actually have to make a show happen at 11 p.m. with an audience in the room.

It is still early (the repository is open, the bridges exist, the schemas are public). But the direction is clear: treat the live creative system as something that can be proven coherent rather than merely assumed coherent.

Different tools. Same universe.

Explore the protocol, schemas, Conductor, and integrations at pchi.life and the open repository. The math is already in the messages. The question is what you will build once every part of the stack speaks the same verified language.

GPU Laser Vision -Turning Live Video into Real-Time Laser Paths and Projector Art

vdmo — Fri, 28 Aug 2026 11:16:32 +0000

For VJs, installation artists, and anyone chasing the intersection of computer vision, GPU compute, and physical light, a new open-source project has landed that feels purpose-built for our world.

GPU Laser Vision by Joshua Batty is a real-time Rust pipeline that takes 720p video (or live sources in future iterations) and converts it into segmented projector output and coloured laser geometry ready for an Ether Dream DAC. It runs two parallel vision paths side-by-side—classic custom CUDA edge detection and modern YOLO11 instance segmentation—then extracts contours, recovers original colours, and packs scanner-safe paths.

The result sits comfortably in the nannou creative-coding ecosystem (Batty is a co-founder of nannou) and already supports fullscreen secondary-display projector isolation plus laser streaming.

Why This Matters for VJs and Live Visual Artists

Most of us already push pixels, particles, and shaders. Few of us have a clean, open, high-performance bridge from camera/video → semantic understanding → actual laser scanners or isolated projector silhouettes without heavy custom engineering or proprietary tools.

GPU Laser Vision gives you:

Two complementary perceptions: dense classical edges (fast, detailed, fragmented) versus clean person silhouettes from YOLO11n-seg.
Colour recovery so the laser or projector inherits the source palette instead of flat white or arbitrary tints.
Live comparison dashboard (nannou + egui) showing intermediate stages, thresholds, performance numbers, and source selection.
Physical outputs ready to go: person isolation on a secondary display, and Ether Dream streaming at up to 30k points/sec with scanner-aware packing (different strategies for dense CUDA edges vs coherent YOLO contours).

Performance on an RTX 5090 is already production-relevant for many setups. With a 1280×720 @ 25 fps source the processing callback sits in the 14.8–15.6 ms range (roughly 64–68 fps of compute headroom). The custom CUDA edge pipeline alone is ~1.8–1.9 ms; YOLO11n segmentation is 9.1–10.1 ms. The media itself is currently the limiting factor.

Architecture at a Glance

Custom CUDA path

RGBA → grayscale → Scharr magnitude + gradients → live threshold + colour sampling along the gradient normal → compact host copy → path tracing into open paths, closed loops, and points. Everything runs as a captured CUDA graph with persistent buffers.

Neural path

Upload/resize/normalize/letterbox on CUDA → fixed 640×640 YOLO11n-seg TorchScript (LibTorch) → strongest person mask restored to 720p → one-pixel contour + green-spill replacement → same path tracer.

Both routes feed the same geometry, colour, display, and point-count surfaces so the comparison stays honest. Projector output isolates the detected person against black. Laser output is explicitly gated and disabled by default—important for safety.

Getting It Running

Requirements are Linux or WSL2 + NVIDIA GPU, Nix with flakes, and a 720p demo clip. CUDA, nightly Rust, LibTorch/PyTorch, FFmpeg, etc. are pinned by the flake—no system CUDA toolkit needed.

git clone https://github.com/JoshuaBatty/gpu-laser-vision.git
cd gpu-laser-vision
nix develop --command uv run scripts/export_yolo.py   # YOLO11n-seg → TorchScript
# place your 1280×720 clip at assets/jcvd_green_screen_720p.mp4
nix develop --command cargo oxide run

Optional Ether Dream: set ETHER_DREAM_IP if discovery fails (common under WSL). Secondary display automatically enables the projector isolation window.

The interface lets you tweak Scharr thresholds live, switch CUDA vs YOLO geometry for the laser, inspect grayscale/Scharr/mask stages, and monitor FPS + stage timings.

Current Scope and Roadmap

The full chain—source → GPU vision → projector / Ether Dream—is already implemented. Next work targets production installation realities: live camera capture, projector/scanner calibration, venue safety integration, and documenting finished light performances.

Safety note (please read it twice): Laser hardware needs proper scan-rate limits, blanking, interlocks, and venue-specific controls. On-screen paths alone are not a complete laser-safety system.

Why You Should Care Right Now

This is the kind of project that lowers the barrier between “I can track a person in Resolume/TouchDesigner/Isadora” and “I can drive a real laser scanner or isolated projection with the same contours and original colours at interactive rates.” It is written in Rust with careful CUDA graphs and Nsight-profiled kernels, licensed AGPL-3.0, and sits in the same creative-coding lineage as nannou.

If you work with lasers, projection mapping, interactive installations, or simply want a high-performance vision playground that already speaks laser geometry, clone it, throw a green-screen clip at it, and start playing.

Repo: https://github.com/JoshuaBatty/gpu-laser-vision

Have you already experimented with computer-vision-driven lasers or person isolation in a live context? Drop your experiences, hardware setups, or questions below—let’s talk about what production-ready versions of tools like this need next.

Daniel Aagentah - what I learned open-sourcing 5 years of audio-visuals

vdmo — Wed, 26 Aug 2026 19:33:58 +0000

Daniel Aagentah: hello friends, it's been about six months since I posted my last video on the project so I thought this would be a good time to reflect on what I've learned so far and outline some new features. I've had a lot of very kind words on the project since and I'd love to see what other people are implementing and creating with it. Thank you for being here.

https://github.com/aagentah/nw_wrld

Processing.org Rust Core

vdmo — Wed, 26 Aug 2026 10:01:10 +0000

Processing is experimenting with a Rust core for modern rendering, and it could open new doors for artists, educators, and creative coders.

https://rustfoundation.org/media/built-with-rust-processing-foundation/

For more than two decades, Processing has been one of the most welcoming entry points into programming for people who think visually. Artists, designers, students, and educators have used it to sketch ideas in code, generate generative art, prototype interactive installations, and learn the fundamentals of computation through immediate visual feedback. Built primarily around Java (with modes and ports for JavaScript, Python, and others), it has always prioritized accessibility and rapid iteration over raw systems-level performance.

That landscape is shifting. The Processing community is exploring a new experimental foundation called libprocessing: a native implementation of the core Processing API written in Rust and powered by the Bevy game engine, with WebGPU as its rendering backend. The project aims to support desktop, mobile, and web targets over time. A talk at Libre Graphics Meeting 2026 framed this as a way to modernize Processing’s rendering while expanding what the project can become.

Why Rust?

Rust brings several practical advantages that map well to creative coding’s evolving needs:

Performance and modern graphics. Older OpenGL-based approaches are showing their age. WebGPU and contemporary GPU APIs enable better use of current hardware, including more efficient rendering, compute capabilities, and future-proofing for higher-resolution or more complex visuals. Rust’s low-level control and zero-cost abstractions help deliver that without the usual C/C++ complexity tax.
Cross-platform and embeddable potential. Because Rust compiles to native code and can expose a C-compatible interface (via FFI), the same core can be called from Java (the traditional Processing environment), Python, or other languages. There is also work toward WebAssembly bindings, which could eventually strengthen browser-based creative tools.
Safety and reliability. Memory safety without a garbage collector reduces entire classes of crashes and subtle bugs—valuable when sketches grow into longer-running installations, generative systems, or tools shared with students.
Access to a rich ecosystem. Building on Bevy gives Processing a modern application and graphics framework to draw from, while still aiming to preserve the immediate-mode, procedural style that makes Processing feel like sketching.

The project is still early and explicitly labeled experimental and unstable. The goal is not a full rewrite that discards the familiar Processing experience, but a shared native core that different language front-ends can use. In principle this could keep the friendly “setup and draw” workflow while improving the underlying engine.

Benefits for the creative community

Creative coders often hit practical limits: sketches that become sluggish with complex geometry or particle systems, difficulty targeting new platforms cleanly, or friction when moving from a classroom prototype to a more robust interactive piece. A stronger native core addresses several of these pain points.

Artists and generative practitioners could work with more ambitious real-time visuals or higher-fidelity output without abandoning the approachable API they already know. Educators might eventually offer students a path that starts with the same friendly syntax and later reveals higher-performance or systems-oriented options. Tool builders and library authors could create new language bindings or hybrid applications more easily if a stable C ABI layer emerges.

The broader creative coding world already has strong Rust options (nannou and others), but an official Processing effort carries unique weight: it keeps the large existing community, documentation, teaching materials, and cultural emphasis on accessibility connected to modern technology rather than forcing a complete migration. It also signals that Processing intends to remain relevant as graphics hardware and deployment targets continue to evolve.

There are trade-offs, of course. Rust’s learning curve is steeper than Processing’s deliberately simplified Java dialect, so most users will continue interacting through higher-level language modes rather than writing Rust directly. The experimental status means features, stability, and documentation will take time. Not every long-standing Processing library will magically transfer overnight. Still, the direction is promising: preserve the creative, exploratory spirit while upgrading the technical foundation.

In short, Processing’s exploration of a Rust-based rendering core is less about abandoning its roots and more about giving the creative community better tools for the next twenty-five years. Faster, more portable, and more capable visuals—without losing the sense that programming can feel like drawing. For a community that has always valued both art and accessibility, that combination is worth watching closely.

libprocessing integrates Bevy as its core application framework and rendering foundation while preserving Processing’s immediate-mode creative coding style.

libprocessing is an experimental Rust library that reimplements the core Processing API as a native, cross-platform layer. It sits on top of Bevy (via a project-maintained fork) and uses wgpu (WebGPU) as the rendering backend. The goal is to support desktop, mobile, and web targets eventually, while exposing a C ABI (via cbindgen and FFI) so languages like Java, Python (mewnala via PyO3), and others can call into it.

Why Bevy?

Bevy’s design aligns well with Processing’s needs:

Modularity and ECS — Bevy is built around an Entity-Component-System architecture rather than a monolithic engine. This lets libprocessing pick only the needed pieces (2D/3D rendering, windowing, input, assets, etc.) and compose them.
Modern graphics — Strong commitment to WebGPU/open standards, which replaces the aging OpenGL/JOGL path used by classic Processing.
Cross-platform and embeddable — Rust + Bevy makes native performance, embedding via C ABI, and targets like desktop (with Wayland/X11/winit), Android, web (via WebAssembly bindings), and more practical.
Broader ambitions — The Bevy community is interested in non-game uses (art, scientific visualization, CAD-like tools), which matches Processing’s creative coding focus.

The project depends on a forked Bevy (https://github.com/processing/bevy, main branch) with a selective feature set (2D/3D Bevy render, UI, picking, scene, winit, multi-threading, fonts, cameras, shader formats, etc.). Patches ensure consistency across Bevy sub-crates. There is a note to eventually return to upstream Bevy once custom needs are resolved.

Technology stack layers

From outer to inner:

cbindgen — Generates C headers for FFI consumers (Java via Project Panama or similar, Python, etc.).
Rust FFI layer — extern "C" functions that map C-compatible types to the libprocessing API.
libprocessing — The primary Processing-style API (procedural/immediate-mode).
Bevy — App structure, ECS, graphics features, windowing, assets.
wgpu — Bevy’s rendering hardware interface (WebGPU).
Vulkan / Metal / etc. — Low-level GPU APIs.

The core architectural challenge: immediate mode on top of retained-mode ECS

Processing sketches are immediate-mode: you call rect(), background(), etc., and drawing happens in sequence with global mutable state. Bevy is retained-mode: a scene database of entities + components, systems that query/transform data (often in parallel), and a separate rendering phase that batches work across frames.

libprocessing deliberately presents the familiar immediate-mode API while implementing it on Bevy’s ECS. This requires inverting several Bevy defaults:

Recording instead of immediate execution — Draw calls do not spawn entities right away. Intent is recorded as DrawCommands into a per-graphics CommandBuffer. This preserves call order and allows controlled batching.
Synchronous frame control — Bevy normally manages its own main loop and pipelined rendering. libprocessing keeps the App in a thread-local and calls app.update() only when the user explicitly flushes (i.e., when a change requires rendering due to data dependencies).
Selective rendering — Cameras are disabled by default (active field). A Flush marker component is added to the relevant surface when rendering is needed. Systems that produce renderable data check for Flush so they only act on the requested surface.
Transient geometry — Shapes exist only for the frame they are drawn. Mesh entities are spawned on flush and despawned before the next frame. The ECS acts as a temporary staging area rather than a persistent scene graph.
Camera write control — Cameras use CameraWriteMode::Skip so intermediate textures are not written to the final RenderTarget until endDraw (or equivalent).

As long as camera state is managed correctly, calling app.update() or individual systems does not trigger unwanted renders or presents.

Practical integration details

Handles, not raw pointers — Long-lived data is represented by Bevy Entity IDs (returned as u64 combining index + generation). Consumers never receive pointers into Rust-owned memory. Destructor functions remove entities and free resources; higher-level language wrappers own the lifetime.
Working with Bevy systems and borrows — Immediate-mode code frequently needs imperative world mutation. Strategies include:
- Running systems via run_system_cached_with that take In<T> (or tuple) parameters.
- Collecting query results into intermediate collections to release borrows.
- Using resource_scope or temporarily removing/re-adding resources.
Threading model — Currently single-threaded on the main thread (important for macOS windowing and simplicity). app.update() runs the main + render schedules blocking; asset loads via Bevy’s AssetServer are blocking. Multi-threading may be explored later for performance.
Error handling and safety — Designed so FFI consumers cannot easily cause undefined behavior or process crashes through normal calls. Errors are treated as exceptional (often halt). Validation helpers can return user-friendly messages.
API philosophy — Closely follows the existing Processing API but fixes historical issues where practical and exposes useful Bevy capabilities (e.g., more texture formats) even if higher-level modes cannot fully use them yet. Naming is descriptive (processing_graphics_..., etc.). Learnings from p5.js are considered.

Current status and related pieces

The project is explicitly R&D / highly unstable (recent releases around v0.0.8). It includes examples for 2D/3D primitives, transforms, materials, PBR, particles (CPU and GPU), text, lighting, glTF, MIDI/audio, input, filters, and more. There is also a Python binding (mewnala) and WASM work. Audio integration has used packages like bevy_seedling.

In short, Bevy supplies the modern, modular, high-performance graphics and app infrastructure. libprocessing carefully layers an immediate-mode Processing façade on top through command buffering, controlled flushing, transient entities, and careful camera management. This keeps the creative, sketch-like experience while unlocking contemporary GPU capabilities and multi-language embedding. The design is still evolving, so details may change as the experimental work matures.

I love surprises very much, and this surprise is a good one! Its real, its believable, you can walk across the room and touch it.

vdmo — Fri, 21 Aug 2026 15:52:14 +0000

A visual node-based editor for Three.js Shading Language (TSL)

vdmo — Wed, 04 Feb 2026 05:43:37 +0000

Create stunning shaders
without writing code

https://www.threejsshadergraph.com/

A visual node-based editor for Three.js Shading Language (TSL).
Build complex effects with an intuitive drag-and-drop interface.

MXR App’s Massive UI Overhaul: A Sneak Peek at the Future of Live Show Control

vdmo — Mon, 26 Jan 2026 06:28:02 +0000

If you’ve been following the development of the MXR App, you know that the team is dedicated to refining the live performance experience. After an intense period of testing and live shows throughout late 2025, MXR Founder Eric just dropped a major update on the subreddit regarding the future of the platform.

https://www.mixerxr.com/

The verdict? A major UI redesign is currently underway.

Based on direct feedback from operators in the field, the team is retooling the interface to make it more intuitive, linear, and responsive. While the design is still a work in progress, here is a breakdown of the exciting features currently on the drawing board.

1. Enhanced Show Control

The biggest takeaway from the recent live testing seems to be usability. When you are in the heat of a performance, you can't be hunting for tiny pixels.

New Control Tabs: Two new tabs are being introduced specifically for "Show Control."
Larger Interface: Expect large buttons designed to make operating MXR significantly easier during live sets.
Better Sliders: Critical parameters are getting larger sliders for more precise control.

2. A New Way to Sequence

One of the most requested workflow improvements is being addressed with a New Sequencer Node. This addition aims to make programming more linear. Crucially, it is designed to allow changes "on the fly," giving VJs and operators the flexibility to adapt to the music without breaking their flow.

3. Advanced Visual Manipulation

The update isn't just about buttons; it’s about what you can put on the screen.

Time Dilation: A fascinating new feature for ramping animation speeds, allowing for dynamic tempo changes.
Emergency/Accent Controls: Dedicated controls for fading to (or strobing) Black or White—essential tools for drops and transitions.
Preview Monitors: While this is still "TBD" based on performance impact, the team is actively exploring the addition of in-app preview monitors.

4. Grouping for Power Users

For those running complex setups, organization is key. The redesign proposes a heavy focus on grouping:

Light Groups: Dedicated controls for managing clusters of lights.
Trigger Groups: Manage visibility or FX across multiple elements simultaneously.
Material Groups: Trigger material changes across a whole group at once.

The "Cutting Room Floor" Disclaimer

Eric was careful to note that this design is currently a work in progress. The team is prioritizing performance and stability, meaning some of these features might not make the final cut if they bog down the system.

We Need Your Feedback!

The MXR team is looking for community input to decide what to prioritize first. If you are an MXR user, head over to the r/MXR_App subreddit and let them know which of these features matters most to your workflow.

Stay tuned for more updates as the redesign progresses!

Code-Driven Chaos: Exploring "nw_wrld" – A JavaScript Generative Powerhouse

vdmo — Sat, 17 Jan 2026 08:16:57 +0000

If you think high-end live visuals are reserved for heavy software like Notch or TouchDesigner, aagentah is here to prove you wrong.

Their latest project, nw_wrld, is a stunning example of how raw code can create immersive, high-intensity environments. Showcased recently on YouTube and open-sourced on GitHub, this project is built entirely using JavaScript.

For the VJ Union community, nw_wrld offers a glimpse into the power of WebGL and creative coding in a live performance context.

The Aesthetic: Digital Brutalism

nw_wrld doesn’t lean on stock textures or pre-rendered loops. Its beauty lies in its math. The visual style is a high-speed collision of:

Fragmented Geometries: Shifting grids and architectural forms that react with violent precision.
Monochromatic Glitch: A heavy focus on contrast, strobe effects, and digital noise that feels right at home in a dark warehouse techno set.
Infinite Landscapes: Because it’s generative, the "world" never repeats, providing a unique experience for every frame.

Technical Breakdown: Why JavaScript?

By building nw_wrld in JavaScript, aagentah taps into the flexibility of the web stack. For VJs, this opens up some unique tactical advantages:

WebGL & GLSL Power: The project leverages the GPU through WebGL. The heavy lifting is done via shaders (GLSL), allowing for complex particle systems and displacement mapping that run at a smooth 60FPS.
Browser-Based Portability: You don't need a $2,000 software license to run this. It runs in a browser. For live setups, this can be easily integrated into Resolume or OBS using NDI (via scan converter) or Syphon/Spout browser extensions.
The "Live Coding" Philosophy: Unlike traditional UI-based tools, JS-based projects allow for deep logic manipulation. You can hook into Web Audio APIs for frame-perfect audio reactivity or use Web MIDI to link your physical faders directly to the JS variables.

A Sandbox for Developers and VJs

The GitHub repository is a goldmine for anyone interested in creative coding. Because it is open-source, VJs can:

Fork the World: Take the existing codebase and inject your own color palettes or camera movements.
Learn the Logic: Study how aagentah handles the sequencing of generative "scenes" using JS logic.
Expand the Input: Add your own event listeners—imagine the visuals reacting to live Twitter feeds, Twitch chat, or complex OSC data streams.

How to Integrate it into your VJ Set

If you’re looking to bring the nw_wrld aesthetic to your next gig:

Clone the Repo: Grab the code from GitHub and run it locally.
Screen Capture / Routing: Use a tool like OBS or Web-Spout to route the browser window into your main mixing software (Resolume, VDMX, Modul8).
Map it: Since it’s JS, you can easily tweak the code to map your MIDI controller to specific parameters within the script.

Final Thoughts

nw_wrld is a testament to the "Post-Internet" VJ aesthetic. It’s raw, it’s fast, and it’s built on the open web. aagentah has provided the community with a powerful template for what's possible when we step outside of traditional VJ software and start writing the visuals ourselves.

Get Involved:

Watch the Demo: nw_wrld on YouTube
Get the Code: aagentah/nw_wrld on GitHub

Are you experimenting with JavaScript or WebGL in your live sets? Let’s talk about it in the comments below!

VJUnion #CreativeCoding #Javascript #WebGL #GenerativeArt #LiveVisuals #Vjing

New Timeline in cables.gl

vdmo — Fri, 14 Nov 2025 14:59:36 +0000

What is the Timeline?

The Timeline is a keyframe-based animation editor in cables.gl that lets you animate any numerical parameter in your patch with precision. It brings professional-grade motion control to your workflow — whether you are fine-tuning logic or shaping movement, timing and easing. With an intuitive interface for keyframes, curves, and clips, the Timeline gives you full visual control over how your projects evolve over time.

https://blog.cables.gl/timeline/

The Fabric Project: Bringing High-Fidelity Interactive Graphics Back to macOS

vdmo — Fri, 24 Oct 2025 14:36:15 +0000

The macOS creative community has been searching for a worthy successor to Quartz Composer ever since Apple deprecated it, and Anton Marini is answering that call with the ambitious Fabric Project—a constellation of modern, open-source tools built on Metal that promises to revive the golden era of node-based visual creation on Apple platforms [10][11][12].

Filling the Void Left by Quartz Composer

For over a decade, Quartz Composer was the beating heart of creative coding on macOS, empowering VJs, visual artists, and multimedia creators to build interactive compositions through an intuitive node-based interface [13][14]. When Apple deprecated QC in macOS Catalina due to its reliance on the now-obsolete OpenGL framework, it left a painful gap in the creative toolchain [13][15]. VDMX recently announced they're officially phasing out Quartz Composer support due to mounting instability from OpenGL-to-Metal bridge issues, making the need for a modern replacement more urgent than ever [13][14].

While Vuo.org has admirably stepped in to fill the Quartz Composer void with a commercial node-based environment that shares many similarities, the Fabric Project represents a distinctly different philosophical approach [1][3][7]. Where Vuo is a polished commercial product built by the team behind the popular Kineme plugins with user-driven development priorities and professional support services, Fabric emerges from a more personal, experimental ethos [4][7]. This is Anton's vision as an artist and tool-maker—open source at its core, Metal-native from day one, and rooted in the hacker spirit of creative exploration rather than commercial sustainability [10][12].

Enter Anton Marini—better known in the creative tech community as vade—a veteran VJ, creative technologist, and former Quartz Composer power user who understands exactly what the community needs [16][12]. Having worked extensively with visual programming environments and developed plugins for Quartz Composer himself, Anton brings both technical expertise and lived experience to this challenge [11][12].

The Three Pillars of the Fabric Project

https://fabric-project.github.io/

Satin: The Foundation

At the heart of the Fabric Project lies Satin, a production-ready 3D graphics framework built on Apple's Metal API, created by Reza Ali [17][18]. Inspired by the elegance of Three.js, Satin provides a comprehensive foundation that includes materials, shaders, geometry systems, and a complete scene graph architecture [17][19]. The framework supports modern rendering techniques including physically-based rendering (PBR), real-time shadows, tessellation, and even ray tracing—bringing cutting-edge graphics capabilities to Apple platforms [17].

Satin was born from real-world production needs, initially developed for Intel Studios to efficiently render massive point cloud datasets on iOS devices at 60fps without overheating [18]. This performance-first approach means the framework is battle-tested and optimized for real-time creative work [18]. While Reza can no longer continue active development due to professional obligations, Anton has stepped up to carry the torch forward and build upon these solid foundations [11][12].

Fabric: The Creative Environment

Fabric is Anton's answer to the node-based editor that the community has been craving—a modern reimagining of Quartz Composer built entirely in Metal, Swift, and SwiftUI [12]. This isn't just a nostalgic recreation; it's a thoughtful evolution that addresses what made QC special while embracing contemporary development practices and Apple's modern frameworks [11][12].

The editor features everything you'd expect from a professional visual programming environment: mesh, material, geometry, camera, and lighting nodes that connect intuitively to build complex visual systems [12]. It supports PBR shading with proper lighting and shadows, post-processing effects, image processing pipelines, shader loading, and 3D model import [12]. The node-based workflow operates on an efficient pull-based system where nodes request data from connected parent nodes each frame, with intelligent dirty/clean marking to optimize performance [11].

What makes Fabric particularly exciting is its cross-platform capability—the engine runs on macOS, iOS, iPadOS, tvOS, and even visionOS, opening up possibilities far beyond what Quartz Composer could achieve [12]. The editor itself is macOS-focused, providing the desktop-class workflow that power users demand, while the runtime engine can deploy compositions across the entire Apple ecosystem [12].

Fabric also introduces an interchange format for saving compositions and an embeddable SDK that allows developers to load and render Fabric documents in their own applications [10]. This means VJ software, live performance tools, interactive installations, and custom applications can all leverage Fabric compositions, creating an ecosystem similar to what existed with Quartz Composer plugins and patches [10].

Velvet: Experimental Live Coding

For those who prefer code to nodes, Velvet offers something truly unique—an experimental live coding environment written in Swift that takes inspiration from Processing [10]. Velvet allows artists and developers to write Satin code and see it compile and hot-load in real-time, bridging the gap between traditional programming and immediate visual feedback [10].

This live coding approach is particularly valuable for performance contexts, shader development, and rapid prototyping where the immediacy of seeing code changes reflected instantly can unlock creative workflows that would be impossible with traditional compile-test-debug cycles [10].

Why This Matters for the macOS Creative Community

Native Metal Performance

By building exclusively on Metal rather than trying to maintain legacy OpenGL compatibility, the Fabric Project delivers the high-performance, low-latency graphics that real-time visual work demands [11][12]. Metal's direct hardware access and modern shader capabilities enable techniques that simply weren't possible in Quartz Composer's aging OpenGL foundation [13][17].

Open Source and Community-Driven

Unlike proprietary solutions, the Fabric Project embraces open-source development, inviting the community to contribute, extend, and shape its evolution [11][12]. Anton is actively seeking to build a community of developers and users who can help maintain and expand the project [10][11]. This collaborative approach means the toolset can grow organically to meet the actual needs of working artists and developers rather than being locked to a single company's roadmap [11].

Professional Yet Accessible

Anton's vision strikes a careful balance between being approachable for creative exploration while meeting professional production requirements [11]. The no-code node-based environment lowers the barrier to entry for designers and artists, while the underlying Satin framework provides the depth and extensibility that technical developers need [10][11]. This dual-level approach means beginners can create compelling work immediately while experts can dive deep into custom shader code and advanced rendering techniques [11][12].

A Platform for Experimentation

The Fabric Project explicitly aims to "bring back an era of high quality, performant and experimental software to the Apple platforms as first class citizens" [10]. This mission statement resonates deeply with anyone who remembers the creative renaissance that Quartz Composer enabled—when VJs, interaction designers, and digital artists had powerful native tools that felt like they were designed specifically for creative exploration [10][13].

The Road Ahead

While Anton describes Fabric as "work in progress," the project is already "relatively capable today" and ready for early adopters to explore [12]. The foundation is solid, the vision is clear, and the development is active [20][12]. Recent updates show Anton optimizing graph evaluation performance and continuing to refine the core engine [20].

For anyone who remembers the joy of patching together visual systems in Quartz Composer, experimenting with generative graphics in VDMX, or building interactive installations with node-based tools, the Fabric Project represents genuine hope [11][13][12]. It's not trying to be a commercial product with flashy marketing—it's a passionate, technically excellent effort to give the creative community the tools they deserve [10][12].

Getting Involved

The Fabric Project is actively looking for community members to contribute, test, and help shape its future [10][11][12]. Whether you're a former Quartz Composer user with ideas about workflow, a Metal developer who can contribute code, or an artist eager to push the boundaries of what's possible, your input is welcome [12]. You can explore the project at fabric-project.github.io and connect with Anton and other community members to be part of rebuilding the creative graphics ecosystem on Apple platforms [10][12].

https://fabric-project.github.io/

The golden age of creative coding on macOS isn't just a memory—thanks to Anton Marini and the Fabric Project, it's being reborn for a new generation [10][12].

Citations:
[1] Looking for an alternative to Quartz Composer? https://vuo.org/qc
[2] alternative for mac? : r/quartzcomposer https://www.reddit.com/r/quartzcomposer/comments/lh5ixw/alternative_for_mac/
[3] Vuo and other visual programming languages https://vuo.org/taxonomy/term/83
[4] Looking for an alternative to Quartz Composer? https://www.youtube.com/watch?v=upO-3yTYPb4
[5] VDMX and Vuo https://docs.vidvox.net/vdmx/vdmx_vuo
[6] Converting from Quartz Composer - Discussions https://community.vuo.org/t/converting-from-quartz-composer/6293
[7] Looking for an alternative to Quartz Composer? - Tutorials https://community.vuo.org/t/looking-for-an-alternative-to-quartz-composer/4783
[8] Alternative for Quartz Composer - Resolume Forum https://resolume.com/forum/viewtopic.php?t=14971
[9] How does Vuo compare to other creative coding ... https://vuo.org/compare
[10] Anton Marini (@_vade) / X https://x.com/_vade
[11] Fabric - A Node based Metal Realtime engine inspired by ... https://www.reddit.com/r/GraphicsProgramming/comments/1khcowt/fabric_a_node_based_metal_realtime_engine/
[12] Anton Marini's Post https://www.linkedin.com/posts/antonmarini_github-fabric-projectfabric-node-based-activity-7378820328451624960-ljw1
[13] Sunsetting Quartz Composer in VDMX6 https://vdmx.vidvox.net/blog/sunsetting-quartz-composer-in-vdmx6
[14] Quartz Composer — Blog - VDMX - MAC VJ SOFTWARE https://vdmx.vidvox.net/blog/tag/Quartz+Composer
[15] Quartz Composer https://en.wikipedia.org/wiki/Quartz_Composer
[16] Interview: Anton Marini on Visual Expression, Exploring ... https://cdm.link/interview-anton-marini-on-visual-expression-exploring-glitch-open-community/
[17] Spring 2021 #OSSTA Lecture: Reza Ali http://opentranscripts.org/transcript/spring-2021-ossta-lecture-reza-ali/
[18] Intel Studios — Real-time Point Cloud Rendering https://www.syedrezaali.com/intel-studios
[19] GitHub - Hi-Rez/Satin: A 3D Graphics Framework built on ... https://github.com/Hi-Rez/Satin
[20] Optimized Swift code for graph evaluation with Instruments https://www.linkedin.com/posts/antonmarini_swift-optimization-programming-activity-7383538316492636160--n_U

Geyser: Seamless Inter-Application Graphics & Texture Sharing for Rust

vdmo — Thu, 23 Oct 2025 04:22:17 +0000

Rust's prowess in high-performance computing, especially in graphics and game development, is undeniable. However, a persistent challenge remains: how do you efficiently share complex data, like textures or render targets, between different applications or even different parts of a single, highly modular system? Enter Geyser, an innovative project that's set to revolutionize how Rust applications interact, particularly when it comes to shared graphical resources.

Found at github.com/compiling-org/Geyser, Geyser isn't just another web framework. It's a foundational layer designed to enable type-safe, high-performance inter-application communication, with a specific emphasis on the secure and efficient sharing of graphical textures and other GPU resources. While WebGPU integration is on the horizon, its immediate impact is in streamlining sophisticated native graphics workflows.

What is Geyser (Really)?

At its heart, Geyser is about bridging the communication gap between disparate Rust applications or modules that need to exchange structured data, especially when that data involves GPU-managed assets. Think of it as a highly specialized, type-safe RPC (Remote Procedure Call) system tailored for scenarios where low-latency data transfer and resource sharing are critical.

Instead of cumbersome serialization/deserialization for every data exchange, Geyser aims to provide mechanisms for direct, efficient sharing, minimizing overhead and maximizing performance. This is particularly crucial for graphics applications where copying large texture data between processes is prohibitively expensive.

Key Innovations and Their Impact

Type-Safe Inter-Application APIs: Geyser leverages Rust's strong type system to define the interfaces between applications. This means that when one application sends data (or a reference to a resource) to another, the types are guaranteed to match at compile time. This eliminates a whole class of runtime errors, making complex multi-application systems significantly more robust. Imagine a render engine passing a processed frame to a display utility, with all data types rigorously checked.

github.com/compiling-org/Geyser

Workbench 5.0 is Beautiful

vdmo — Sun, 19 Oct 2025 15:05:36 +0000

Blockbench is a free, open‑source low‑poly 3D editor with pixel‑art texturing and a built‑in Animate workspace for bone/keyframe animation, making it a fast path from modeling to motion for real‑time visuals. It exports to production formats like glTF/glb, FBX, and DAE so the same animated assets can run in browsers, game engines, and VJ pipelines, including Three.js playback in the web.[1][2][3][4]

Website: https://www.blockbench.net
Github: https://github.com/JannisX11/blockbench

Blockbench at a glance

Blockbench focuses on low‑poly modeling with pixel‑art textures, ships a modern, beginner‑friendly UI, and supports deep customization through plugins for advanced users and workflows. It handles standardized exports for general 3D use and has dedicated formats for Minecraft Java and Bedrock when you need game‑specific features and animation integration.[1]

Why VJs should care

The glTF/glb export preserves hierarchy, materials, and animation while keeping assets lightweight and web‑friendly, which is ideal for browser‑based shows and real‑time playback. Three.js loads glTF 2.0 directly via GLTFLoader, so your Blockbench animations can be streamed into a scene and driven live with mixers, timelines, or MIDI/OSC bridges.[3][4][5]

Animate in Blockbench

Set up a clean bone hierarchy with sensible pivots so each movable piece rotates around the right point; use the Pivot tool and a root bone to control the whole figure.[2]
Switch to the Animate tab, create a named animation, and keyframe rotation/position/scale on the timeline; Blockbench auto‑generates keyframes when you adjust transforms at new times.[2]
Use the playhead to preview loops, tweak timing, and refine secondary motion; save your project to keep animation data alongside the model.[2]

Export for production

glTF/glb is the go‑to for web and Sketchfab, FBX is preferred for Unreal/Unity, and DAE is great for Blender/Unity interchange; OBJ is widely supported but lacks hierarchy/animations and is best for static objects. Blockbench’s export menu lives under File → Export, with guidance for program‑specific setup like pixel‑perfect filtering and alpha modes in DCCs/engines.[3]

Use case	Recommended format
Browser/Godot/Sketchfab	glTF/glb, with embedded textures and animation support [3]
Unreal Engine	FBX for robust engine import workflows [3]
Unity	FBX or DAE depending on pipeline needs [3]
Blender (rendering)	glTF for materials/animation fidelity [3]
Blender (modeling)	DAE for interchange editing [3]
Static meshes	OBJ (no animations) [3]

Play it in Three.js

GLTFLoader loads glTF 2.0 scenes, meshes, materials, skins, morph targets, and embedded animations, keeping asset delivery efficient for the web. AnimationMixer plays AnimationClips on a model, while AnimationAction handles play/pause/loop/blending for clip control and seamless transitions in a live set.[4][5][6]

import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js'
import { AnimationMixer, LoopRepeat } from 'three'

// load model + animations
const loader = new GLTFLoader()
let mixer, actions = {}

loader.load('models/character.glb', (gltf) => {
  const model = gltf.scene
  scene.add(model)

  mixer = new AnimationMixer(model)

  // assume multiple clips exported from Blockbench
  gltf.animations.forEach((clip) => {
    const action = mixer.clipAction(clip)
    action.setLoop(LoopRepeat)
    actions[clip.name] = action
  })

  // play a specific Blockbench clip by name
  actions['Idle']?.play()
})

// in your render loop
const clock = new THREE.Clock()
function render() {
  const dt = clock.getDelta()
  if (mixer) mixer.update(dt)
  renderer.render(scene, camera)
  requestAnimationFrame(render)
}
render()

Use mixer.timeScale for tempo sync, or switch actions with crossfading for scene changes while keeping CPU overhead predictable.[5][6]

Pro tips for VJ performance

Keep geometry lean and texture resolutions modest; glTF supports pixel‑perfect filtering for crisp art‑direction in low‑poly/pixel‑art styles.[3]
Export multiple short loops as separate clips and blend them with AnimationAction to move between states without pops, using clampWhenFinished and blend modes as needed.[6]
Drive speed with mixer.timeScale for BPM‑locked motion, and pre‑load GLBs to avoid hitches during live transitions.[5]

Extend with plugins

Plugins are JavaScript files registered with Plugin.register, can target desktop or web variants, and are hot‑loadable for rapid iteration, enabling custom exporters, tools, or QC checks for show pipelines. The Plugin API and reference docs cover metadata, lifecycle hooks, and TypeScript typings for better autocompletion and stability in complex setups. Notably, while Blockbench’s core is GPL‑3.0, plugins/themes may be proprietary or paid, which suits studio toolchains and marketplace distribution.[7][8][1]

Open source and builds

Blockbench is GPL‑3.0 licensed; clone the repo, install dependencies, bundle, and run dev to hack features, test plugins, or tailor exports for your venue pipeline. The project ships frequent releases, with recent updates continuing to refine collections, selection, and workflow polish for production use.[1]

Quick VJ checklist

Model low‑poly with clean bone pivots for performant, predictable animation.[2]
Animate in the Animate tab and preview tight loops with clear clip names.[2]
Export glTF/glb for web playback; keep textures embedded for simpler deployment.[3]
Load with Three.js GLTFLoader and play clips via AnimationMixer/AnimationAction.[4][6][5]
Use mixer.timeScale and action crossfades for tempo‑aware transitions on stage.[6][5]

With Blockbench’s approachable modeling, keyframed animation, and glTF export, creating live‑ready 3D loops for browser‑based shows becomes a fast, repeatable pipeline from concept to stage visuals.[4][3][2]

Here are the links, now displayed as clickable URLs: