nw_wrld runs your visual modules as trusted code in a portable folder

Two windows: you compose in one, the audience sees the other

The architecture is small enough to hold in your head. Signal sources, either the built-in sequencer or an external MIDI, OSC, audio or file input, feed the Dashboard, and the Dashboard drives the Projector, which is the window the visuals render into. The two-window split is the reason the app can sit on a laptop while the output goes to a projector, and it is visible in the development start script, which builds the runtime, starts a webpack dev server, waits for it on http://localhost:9000 and only then launches Electron against it. The build story is TypeScript in four lanes, with separate tsconfig files for the core, the runtime and the scripts, and separate typecheck commands for the first two. That separation is not decoration: modules written by users are compiled and injected differently from the app itself, and a script named check:runtime-lane exists specifically to detect duplicate sources in that runtime lane.

A project folder is executable code, and the README says so

The security boundary of this project is stated in one sentence in the project folder section: workspace modules are JavaScript code executed by nw_wrld, and only project folders you trust should be opened. That warning matters more here than in most tools, because portability is the headline feature. A project is a self-contained folder with three things in it, modules/ for your hot-reloadable visuals, assets/ for images and JSON, and nw_wrld_data/ for tracks, settings and recordings. The README's pitch is that you can copy that folder to share it, move it between machines, or back it up. Both halves of that are true, and together they mean a project folder from a stranger is a program from a stranger that happens to render graphics, with the same privileges as the app. The roadmap records an isolated sandbox and module-workspace bundling as done, which is the right direction, and the roadmap also records the missing piece: userdata, module and JSON versioning with migration scripts is still unchecked.

The 16-step grid is the whole first-run experience

The quick start is written as a 60-second test and it is worth following literally, because it teaches the mental model. Create a track and name it. Add a module, choosing Text or Corners from the 22 starter modules that a new project is scaffolded with. Add a channel, which is a sequencer row inside that track. Click cells in the 16-step grid and they turn red. Assign a method to the channel, for example color or rotate. Press play in the footer, and the playhead moves across the grid and fires your visuals. The design idea underneath is the feature list's phrase flexible method mapping: rather than binding fixed events, you point a step or an external signal at any method a module exposes, so the same module works as a metronome in a prototype and as a strobe in a show. Modules can be disabled per track without losing their configuration, which is what makes a live set survivable.

MIDI, OSC and audio each bring their own failure mode

External control is the reason this is not just a step sequencer. You can drive it from a MIDI controller or a DAW, from an OSC sender, from a microphone or loopback audio device, or from an uploaded audio file. The DAW section is the most practically useful part of the documentation, because it names a specific trap: most DAW setups send notes on MIDI Channel 1 unless you explicitly route or change it. nw_wrld supports both a single-channel workflow and a split-channel one, where method triggers arrive on one channel and track selection on another, and the Getting Started document walks through the channel defaults. For audio and file modes you get per-track signal settings, a threshold and a trigger cooldown, which is what stops a sustained tone from retriggering every step. The roadmap shows where the audio side is going and, more usefully, where it is not: multi-band threshold analysis for channel triggers is done, while an advanced default sequencer described as a working sampler with audio FX is not, and serial port input for hardware sensors is also still open.

Run it from source, and know what npm start actually does

Installers are published through GitHub Releases for macOS, Windows and Linux, and the README also documents running from source, which needs Node.js 20 or newer. The documented sequence is short:

# 1. Clone the repository
git clone https://github.com/aagentah/nw_wrld.git
cd nw_wrld

# 2. Install dependencies
npm install

# 3. Start the app
npm start

Two windows open: the Dashboard for tracks, patterns and visual configuration, and the Projector for the visual output. Nothing else is required, and no database or service is involved. On first launch the app asks you to select or create a project folder and then scaffolds a working one for you, 22 starter modules covering 2D, 3D, text and data visualisation, plus sample assets and the data directory. If the folder is later deleted, moved or disconnected, the app prompts you to reselect it rather than failing. The version constraint is the badge at the top of the README, Node 20.0.0 or newer, with Electron 39.8.10, and the repository carries an .nvmrc for that reason.

Playwright drives the real Electron app, not a mock

The testing story is unusual for a creative tool and it is a good sign about how the project is built. The end-to-end suite launches the real application and controls its windows through Playwright, with failure artefacts, screenshots and traces, written to a test-results/ directory that is gitignored. The command is one line:

npm run test:e2e

The interesting detail is NW_WRLD_TEST_PROJECT_DIR, an environment variable that boots the tests into an isolated project folder, which means a test run cannot write into the folder you actually work in. Below that sits a unit layer that does not use Playwright: test:unit builds the runtime, runs the runtime-lane duplicate-source check and then executes node --test over test/*.test.js, using the Node test runner rather than a framework. Everything is chained by one script, all:test, which runs the typechecks, the unit tests, the end-to-end tests and lint in order:

npm run all:test

The repository also separates documentation by concern, with GETTING_STARTED.md, MODULE_DEVELOPMENT.md, E2E_TESTING_GUIDELINES.md and RUNTIME_TS_TESTING_GUIDELINES.md, which tells you where a rule lives before you go looking.

Every release is a beta, and the versions do not migrate yet

The maintenance picture has one clear message. The three visible releases are v0.5.0-beta from 2026-02-17, v0.6.0-beta from 2026-04-02 and v0.7.0-beta from 2026-08-21, package.json reports 0.7.0-beta, and the last push was 2026-09-13. The Beta Notice says there may be frequent breaking changes between releases. The unpinned roadmap item that bites hardest is userdata, module and JSON versioning with migration scripts, still unchecked, which sits awkwardly next to the portability promise. If you build a show on this and the folder format moves, a project saved in one release is not guaranteed to open cleanly in the next, and the recovery path the README documents is for a missing folder rather than a changed one. The licensing is GPL-3.0, which matters for an installation-based tool in a commercial venue, and the signed builds are a genuine positive: notarized macOS apps and signed Windows apps are done, with Linux and WSL support marked robust.

Against TouchDesigner, against a DAW with a visual plugin

TouchDesigner is the obvious comparison, and the difference is where the code lives. In TouchDesigner you build a node network out of existing operators, which is faster to assemble and far deeper out of the box, with shaders, devices and analysis nodes you did not write. In nw_wrld you write a JavaScript file, using p5.js, Three.js, D3 or nothing at all, and you get hot reloading, a folder you can commit to git and a trigger surface aimed at someone holding a controller on a stage. What you give up is everything the ecosystem already built, which is why the roadmap still lists use-case specific user guides for Ableton, strudel and TouchDesigner as unfinished: this project is not trying to be a visual programming environment, it is trying to be a box that fires your web code at the right moment. A DAW with a visual plugin is the third option, and it inverts the relationship: the audio tool drives, and the visuals are an output. If your work is a set rather than a track, a DAW's scene and clip launching may already be the right shape.

Editorial conclusion

Adopt nw_wrld if you build visuals in p5.js, Three.js or D3 and want a performer-friendly trigger surface, since hot reloading a module and mapping any of its methods to a step or a MIDI note is the whole product. Do not adopt it to open project folders from other people, because the README states that workspace modules are JavaScript code executed by nw_wrld, and do not adopt it for archived work, because every release so far is a beta and the roadmap still has data and module versioning with migration scripts unchecked. Verify four things: that you have Node 20 or newer and can run npm start to get both the Dashboard and the Projector windows, that your modules declare their dependencies as docblocks so the runtime can inject them, that npm run test:e2e passes on your machine since it drives the real Electron app through Playwright, and how you will pin a version, given v0.7.0-beta from 2026-08-21 and the last push on 2026-09-13. The project is GPL-3.0.

Frequently asked questions

Official sources

1. aagentah/nw_wrld on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases