# Chataigne is the conductor that sits between your show software and your sensors

> Chataigne is a JUCE-based Windows, macOS and Linux application that routes OSC, MIDI, DMX, serial, MQTT and a dozen more protocols between show software, hardware and sensors, with a state machine, a timeline and a Parrot recorder for replaying inputs. The catch for anyone building it is that it needs a patched JUCE fork and a self-built Projucer.

**benkuper/Chataigne** — Artist-friendly Modular Machine for Art and Technology

- Repository: https://github.com/benkuper/Chataigne
- Website: https://benjamin.kuperberg.fr/chataigne
- Stars: 1,690 · Forks: 100
- Language: C++
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/benkuper-chataigne

## The value is in translation, not in doing the work itself

Chataigne describes itself as a conductor rather than a performer, and the README is explicit that it will not do much by itself. Its purpose is to sit in the middle of a project made of several interfaces, software packages, devices and sensors, and keep them synchronised.

That framing predicts the architecture. Anything that can speak one of the listed protocols can be a module, so the protocol list is the feature list: OSC, OSCQuery, MIDI, DMX covering Enttec OpenDMX, Enttec DMXPro, Enttec DMX-MkII, Art-Net and sACN/E1.31, Serial, UDP, TCP, HTTP, MQTT, WebSockets, PJLink, Ableton Link and PosiStageNet. The Module Router then exists to move values from one software to another independent of protocol, which is the piece that makes a mixed-vendor show manageable rather than a pile of point-to-point links.

On the hardware side the list covers Buttplug devices through Intiface Central, KinectV2 on Windows only, StreamDeck, Loupedeck, joystick, gamepad, mouse, keyboard, Wiimote, Joycon, sound card, and GPIO on Raspberry Pi.

For software there are pre-configured modules for Resolume, Madmapper, Millumin, TouchDesigner, Unity, QLab, HeavyM, D::Light, Reaper, Ableton Live through an M4L patch, Powerpoint and Watchout, plus a community list including Leap Motion, EOS-OSC, OBS, Blackmagic Atem-OSC, Flowtoys, Lighttoys FT Props, Midas M32 and an X-Touch.

It uses C++ and JUCE, with compiled Windows, macOS and Linux builds, plus betas and a per-commit bleeding-edge section on the same download page.

## State Machine, Time Machine and Parrot cover the three interaction shapes

The named subsystems do the real work. State Machine builds real-time interactions and automations as explicit states, which is how you express something like idle, playing and reset without a tangle of conditionals.

Time Machine handles the linear case: sequenced animations of values and colours, event triggers and audio playback. That is the mode a show with a running order needs, and it is the same problem the show software it drives already solves, so the point is sequencing across software, not inside one.

Parrot is the distinctive one. The README describes it as recording and playing back datasets of any parameter animation across the whole software, to simulate input and behaviours. Practically, it is a motion capture for control values: record a sequence of parameter changes, then replay them against a different software or in a different configuration to test how something behaves. For an engineer validating a new installation before opening to the public, that is the capability that saves the most time.

Custom Variables store and manipulate values with presets and interpolation over groups of values. The Dashboard builds your own controls, with custom colours and labels, controllable from a web interface. Detective watches how a parameter evolves over time to explain what a system is actually doing, which is the tool you reach for when an installation misbehaves and you cannot see why. The Outliner shows the whole session hierarchy in one place.

The through-line is observability and replay. Chataigne is built for projects where the failure mode is a stack of packages quietly disagreeing, and someone needs to see the values.

## Controlling Buttplug devices means Intiface Central, ports and mDNS

The most detailed section of the README covers the Buttplug hardware module, which is worth reading as a model of how the external integrations behave.

Start the WebSocket server in Intiface Central, then add Hardware > Buttplug in Chataigne. The default server address is `127.0.0.1:12345`, and a `ws://` or `wss://` URL can be entered instead. The module speaks Buttplug protocol v3, discovers devices when it connects, and reconnects on its own once the server is available.

Two failure modes are documented, and both are the kind you hit in the first ten minutes. The port may not be 12345 at all, because another application already holds it; the Leap Motion server is named as a likely culprit, which is a good clue about what collides in practice. And for a server on another machine, Intiface has to be configured to allow local network connections. Connection problems surface through Chataigne's normal warning and log messages.

There is a discovery path for the case where you do not want to type addresses. Enable Broadcast Server Info via mDNS in Intiface's advanced settings before starting the server, then click Auto Detect in the Buttplug module. Chataigne browses `_intiface_engine._tcp.` and fills in address, port and WebSocket path. Servers on the same machine resolve to loopback.

Once connected, devices appear under Values with a Device Index and their supported Features. You use that device index in the Vibrate, Set Scalar, Rotate, Linear and Stop Device commands. A Feature Index of -1 targets every matching feature; otherwise it is the zero-based index within that command's feature array. Vibrate filters scalar features down to vibration motors. Actuator values run from 0 to 1 and linear movement duration is in milliseconds.

Two behaviours are stated that you should design around. Stop All Devices is sent before disconnecting or when the module is disabled, so an actuator cannot be left running. Actuator values are not restored on reconnect, though. And because Intiface provides the hardware and Bluetooth support, no separate device driver is needed on the Chataigne side.

## Building requires a patched JUCE and a Projucer you compile yourself

This is where the friction is. Chataigne uses a modified version of JUCE, so the upstream Projucer will not open the project correctly, and the README requires building your own from the author's fork:

```bash
git clone --branch=develop-local https://github.com/benkuper/JUCE
```

From `JUCE/extras/Projucer/Builds` you open the solution for your system in an IDE, or run make on Linux, and get a new Projucer binary. Chataigne itself needs the recursive clone because the organicUI and timeline modules come in as submodules:

```bash
git clone --recursive https://github.com/benkuper/Chataigne
```

The rest is the standard Projucer sequence: open `Chataigne.jucer`, set your Global Paths, save the jucer file, open the generated solution under Builds, and build it. On macOS, Xcode from the Mac App Store is required.

So a first build is not `git clone` and run. It is clone a framework fork, compile a project generation tool, generate the IDE files, then compile the application.

The repository layout matches that story: `Chataigne.jucer` at the top, `Builds/`, `Source/`, `Modules/`, `External/`, `JuceLibraryCode/`, `Tools/` and `Resources/`, plus `.gitmodules` for the submodules. There are Windows build helpers in `build.bat` and `build_dev.bat`, an Inno Setup script in `install.iss`, a Linux dependency script in `install_linux_deps.sh`, and a legacy `appveyor_legacy.yml` CI file. An `AGENTS.md` at the root sets expectations for agent-assisted work on the codebase.

## No tagged releases, and the download page is the release channel

The repository has no GitHub releases at all. Distribution runs through the project website, which the README gives as the download location for Windows, macOS and Linux, with the note that beta versions appear on that page when they exist, and that a bleeding-edge build is generated at each commit for people who want the newest features and commits.

That is a coherent scheme for a desktop tool with no API surface, but it means version numbers are not the way to pin what you run. In a show, that matters: a build that changes every commit is exactly what you do not want between dress rehearsals, and there is no tagging mechanism visible in the repository to freeze a known good build. The practical answer is to download a specific file once, keep it locally, and avoid the bleeding-edge section until you are deliberately testing.

Development is active regardless. The repository is not archived and the last push was on 2026-10-15.

The licence is GPL-3.0, which is the second constraint for anyone considering it. Using Chataigne to control a show is fine. Shipping it inside a product or a closed installation you distribute carries copyleft obligations, and that question belongs with whoever owns licensing, not with this article. Nothing in the README addresses licensing beyond the LICENSE file at the root.

## Where Chataigne overlaps and where it does not

The comparison that matters is with the software it already controls.

Chataigne earns its place in the specific case the README describes: a project involving multiple interfaces, software and sensors at once. Then the point is not any single timeline but that one state change reaches TouchDesigner, Millumin and a DMX universe at the same moment, over whatever protocol each of them speaks. Its role is to coordinate values across multiple software packages and sensors.

The other overlap is OSCQuery. Because Chataigne speaks OSC and OSCQuery, it can be the server that a browser interface or another tool discovers and talks to, which is a different role from being a controller.

Against a lower-level alternative, such as writing your own OSC bridge in Python or using a general-purpose visual patcher like Node-RED or Max/MSP, the difference is domain fit. Chataigne ships ready modules for a dozen show packages, device-level actuator commands with feature indices, and the Parrot replay tool. You give up the ability to treat it as a general dataflow canvas, and you inherit a GPL-3.0 desktop application rather than a library you can embed anywhere.

## Conclusion

Chataigne fits an installation or show engineer who already has several packages speaking different protocols and needs one place to translate, sequence and replay them, and who is prepared to work inside a JUCE project rather than a JavaScript runtime. Do not reach for it when a single OSC connection would do, when you need a headless service with no UI, or when GPL-3.0 blocks your distribution. Verify first that your platform has a compiled download on the download page rather than relying on the build, that the target software module exists in the list, and that Intiface Central is reachable on the port you configure before building anything else.

## FAQ

### What is Chataigne used for?

It acts as the central hub in a project involving multiple software packages, devices and sensors, synchronising them for shows, interactive installations or prototyping. The README describes it as a conductor that controls all the software with the big picture in mind.

### How do I connect a Buttplug device to Chataigne?

Start the WebSocket server in Intiface Central, then add Hardware > Buttplug in Chataigne. The default server is 127.0.0.1:12345, or you can enter a ws:// or wss:// URL. Intiface handles the hardware and Bluetooth support, so no extra drivers are needed.

### What port does the Chataigne Buttplug module use?

The default is 12345, but the README notes the port may differ if another application already uses it, naming Leap Motion as an example. You can also enable Broadcast Server Info via mDNS in Intiface and use Auto Detect in the module.

### How do I build Chataigne from source?

Clone the develop-local branch of benkuper/JUCE and compile its Projucer first, since Chataigne uses a modified JUCE. Then `git clone --recursive https://github.com/benkuper/Chataigne`, open Chataigne.jucer in your new Projucer, set Global Paths, save, and build the generated solution. Xcode is required on macOS.

### Does Chataigne have tagged releases?

No GitHub releases exist for the repository. Builds are published on the project website at benjamin.kuperberg.fr/chataigne, which also hosts beta builds and a bleeding-edge build generated at each commit.

### Can Chataigne replay recorded input?

Yes. The Parrot module records and plays back datasets of any parameter animation across the whole software, which the README describes as a way to simulate input and behaviours.

## Sources

- [benkuper/Chataigne on GitHub](https://github.com/benkuper/Chataigne)
- [Issues](https://github.com/benkuper/Chataigne/issues)
- [License: GPL-3.0](https://github.com/benkuper/Chataigne/blob/master/LICENSE)
- [Project website](https://benjamin.kuperberg.fr/chataigne)
- [README](https://github.com/benkuper/Chataigne/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/benkuper-chataigne