VOID Shared Memory — Real-time shared memory communication between Max & TouchDesigner
Hi everyone,
I’d like to share a research-oriented project developed at Structure Void, centered around real-time data exchange in Max and Max for Live, with a strong focus on low-level implementation, stability and performance.
VOID Shared Memory is a system designed to connect Max, Max for Live and TouchDesigner using local shared memory, allowing continuous parameters, envelopes, triggers and arbitrary data to circulate between environments with very low latency and deterministic timing, without relying on OSC, MIDI or any network-based protocol.
Project page (documentation & overview):
https://structure-void.com/tools/void-shared-memory/
Demo playlist (Live ↔ TouchDesigner workflows):
https://www.youtube.com/playlist?list=PL1jAw-VM7x1bIBdWO3WS6hUXiz-jpJQOY
Download (Gumroad):
https://structurevoid.gumroad.com/l/Void-SharedMemory
c
On the Max side, the project includes:
Custom Max externals written in C++ (reader / writer)
A set of Max for Live devices built on top of these externals
Tools for data generation, analysis, encoding and transmission directly from Live
On the TouchDesigner side, the same shared memory layer is accessed via custom CHOP operators, also developed in C++, ensuring a consistent and controlled data pipeline across environments.
This is not a closed or monolithic tool, but a technical foundation: a collection of modular, low-level components developed entirely in-house, designed to be readable, hackable and reusable for advanced Max-based systems.
Typical Max-oriented use cases include:
High-performance parameter streaming from Max / Live to external systems
Audio-driven control (envelopes, frequency analysis, triggers) without OSC overhead
Deterministic synchronization between Max-driven audio and visual engines
Experimental control architectures beyond standard Max messaging
The project is distributed as part of an ongoing R&D initiative, and includes:
Max externals (C++)
Max for Live devices
TouchDesigner custom CHOPs
Ableton Live demo sets
TouchDesigner demo networks
All components are provided together to support experimentation, inspection and reuse.
I will likely continue to develop additional Max for Live devices on top of this shared memory layer, and I’m also planning to release an unofficial Max package gathering the core externals and related tools, to simplify standalone Max usage.
Compatibility note (brief): Max externals & Touchdesigner CHOPs are provided as universal binaries. Due to current host-level constraints, Max for Live devices are officially supported on Apple Silicon systems.
Happy to discuss implementation details, SDK aspects or Max-oriented workflows.
Julien
That's huge, thanks for sharing this!
Not a TD user, but I can foresee how useful it can be for single-computer A/V setups requiring tight timing .
Out of curiosity, what determines the refresh rate of this shared memory? And what kind of data can be shared beside floats?
Thanks!
The shared memory itself doesn’t impose any refresh rate — it’s just a low-level memory buffer.
What defines the effective update rate is the writer side (Max / Max for Live or TouchDesigner), i.e. how often data is written into the shared memory.
In practice:
In Max / Max for Live, data can be written at control rate or audio-driven rates (e.g. envelopes, analysis), with optional decimation when needed.
In TouchDesigner, reads typically happen at the CHOP cook rate (often tied to the frame rate), but can be higher or lower depending on the network setup.
So the system adapts naturally to the timing model of each environment, without enforcing a fixed “network-style” refresh.
Regarding data types, the shared memory layer is intentionally simple and deterministic. It currently handles:
floats (single values or arrays / channels)
vectors of floats (multi-parameter streams, envelopes, analysis bands)
This covers most time-critical control and analysis use cases. The focus is on continuous numeric data, rather than structured messages or symbolic data (which are better handled by OSC, JSON, etc.).
As this is part of Structure Void’s ongoing research and development work, there’s room to extend and refine the system over time. I’m planning to:
improve and consolidate the core shared-memory layer,
properly port and support Windows workflows (the Max externals already compile and run on Windows),
and release a pure Max package with dedicated documentation, focused on standalone Max usage and integration.
The idea is to keep it evolving as a solid technical foundation rather than a frozen tool.
Actually, I also have externals for messages/scheduler transmission. Works the same. Useful as prepend/route are enough to parse or write n channels....
ASAP,🤘🏻