EW/OBJECTS

Modular audio environments — Max/MSP, SuperCollider, Pure Data — are powerful but fundamentally monolithic: they run as single processes on single machines, their patch state is opaque binary or serialized text that requires identical software to open, and real-time collaboration means screen-sharing rather than actually sharing signal flow. If you want to patch an oscillator on your laptop into a filter on someone else's, or let a collaborator tweak a sequencer while you shape the timbre, the existing tools offer no native path.

EW/OBJECTS treats each synthesis module as an independent browser page and replaces patch cables with WebSocket node subscriptions, making signal routing a network primitive rather than an application feature. The result is a modular environment where patches are URLs, connections can span tabs or machines, and the only installation requirement is a browser. 111 modules across synthesis, effects, sequencing, modulation, routing, analysis, AI, live coding, visualization, and emulation.

Control signals flow between modules at ~100 Hz — the same publish/subscribe pattern that Max/MSP uses with send/receive, SuperCollider uses with buses, or Pd uses with send/receive, except the connection layer is the network itself. Audio-rate DSP runs locally in each browser tab via Tone.js and the Web Audio API. Modules can live in tabs on one machine, across machines on a LAN, or across the internet with multiple players patching into the same signal graph simultaneously.

Beyond the core synthesizer modules, the platform integrates with external open-source libraries and audio languages — all running entirely in the browser via CDN with no build step. AI-powered melody and drum generation (Google Magenta.js), real-time audio feature extraction (Meyda, Essentia.js), pitch detection, music theory (Tonal.js), and notation rendering (VexFlow). Live coding environments including Glicol (Rust-to-WASM), Mercury, and Orca. Physical modeling synthesis (Karplus-Strong, modal, waveguide) and granular time-stretching. Hardware bridges for MIDI (WebMidi.js), serial (Arduino/ESP32), and Web Audio Module 2.0 plugins. Visual synthesis with Hydra (live-codeable GLSL video synth) and ISF shaders. Every integration speaks the same WebSocket signal protocol — outputs from AI generation feed into sequencers, audio analysis drives visual synthesis, and hardware sensors modulate any parameter in the graph.

1. Open the NETWORK MAP dashboard -- this is your patching interface. Click + ADD OBJECT to spawn any module from the full 111-module catalog. Each module opens as a draggable, resizable popup window inside the dashboard, loading the full module UI and automatically connecting to the WebSocket server.

2. Each module claims a unique node name on load (something like osc-A2WG9E). Click the node name in a popup's header bar to copy it.

3. To connect two modules, click an outlet port (the dots along the top edge of a popup window) to start a wire. A cable appears and follows your cursor. Click an inlet port (the dots along the bottom edge of the destination popup) to complete the connection. Hovering over any port reveals a tooltip with the port name, type, and range.

4. Alternatively, you can paste a node name directly. Click any unconnected inlet port to reveal a text field, paste or type a node name, and press Enter. The port dot turns green once data flows and yellow while waiting for signals. Connected ports can be clicked to reveal a disconnect option.

5. Parameter changes on the source module propagate in real-time to every subscriber. Sweep the oscillator's frequency and the downstream filter tracks it. Chain as many modules as you want -- the signal graph is arbitrary and there is no fixed limit on connection depth or fan-out. Wires animate and track popup positions as you drag, scroll, and resize.

6. To bring someone else into the patch, send them a node name or URL. They click an inlet port on their own module and paste the node name into the text field -- they are now subscribed to your signal output. Multiple users can monitor or process the same node simultaneously -- same as sharing a Bus in SuperCollider, except the Bus spans the network.

7. Nodes can be set to private, restricting signal flow to only those who know the node name -- useful for isolating sub-patches or running a closed session. Private dashboards can toggle visibility of public nodes with the PUBLIC NODES button. The server itself is a standard Node.js WebSocket process -- clone the repo, run npm install and npm start inside the EW-objects/ directory, and you have your own signal relay running on localhost:3001. Point your modules at that local address instead of the public server and all traffic stays on your machine or LAN -- no internet round-trip, minimal latency, and only devices you allow on your network can connect. This is ideal for live performance setups, private jam sessions, or development without depending on an external host.

Every parameter on every module is built on a standardized registerParam system. Each registered parameter is exposed as an inlet port on the popup window, with support for incoming automation from any other module in the network.

When you connect a source outlet to a parameter's inlet port, two things can happen: if the source sends a bipolar signal (ranging from -1 to +1, like an LFO), the parameter is modulated around its current base value by a configurable depth -- the knob position stays the same but the actual value oscillates above and below it. If the source sends a direct value (like a frequency in Hz), the parameter is set to that value outright.

The port dot indicates connection state: grey = no connection, yellow = connected but waiting for signals, green = receiving live data. When automation stops (the source goes silent for ~150 ms), the parameter smoothly ramps back to its base value automatically.

Effect and instrument modules that process audio use a standardized audio input system. When you connect a source node to the audio inlet port, the module auto-creates a local oscillator that mirrors the remote signal's frequency, waveform, and gain -- all DSP runs locally at audio rate, with only control data traversing the network.

The entire state of a patch -- every module, every connection, every parameter value, and every layout position -- can be saved to a single .ewpatch.json file and restored later. This is total recall for your signal graph.

Exporting: Click EXPORT PATCH in the dashboard header. The system queries every open module for its current state (registered params, subscriptions, custom state, and layout coordinates) and downloads a timestamped JSON file. Everything needed to reconstruct the patch is captured -- node names, connection mappings, parameter values, window positions and sizes, even collapse state.

Importing: Click IMPORT PATCH and select a .ewpatch.json file. The dashboard tears down the current session, spawns every module from the patch with its original node name, waits for all WebSocket connections to establish, then restores parameters in Phase 1 and subscriptions (connections) in Phase 2. The two-phase restore ensures all nodes exist on the server before any module tries to subscribe to another -- connections always resolve cleanly.

URL sharing: Click PATCH URL in the dashboard header to compress the current patch into a shareable URL. The full patch state is LZ-String compressed into the URL hash fragment (#patch=...) and copied to clipboard. Anyone who opens the link gets an independent instance of your patch -- fresh node names are generated on every load so multiple viewers never collide on WebSocket nodes. If the patch exceeds ~32 KB when encoded, use EXPORT PATCH (file download) instead.

Example patches via URL: Append ?example=name to the dashboard URL to load a named example patch directly (e.g. dashboard.html?example=basic-fm). The dashboard fetches the patch from EW-objects/example-patches/, remaps all nodes to fresh names, and imports it. The #patch= hash takes priority over ?example= if both are present.

Example patches: Use the dropdown in the dashboard header to load pre-built patches (Basic FM, Basic Drums, Filter Sweep) that demonstrate common signal routing patterns. These ship with the repo in EW-objects/example-patches/ and serve as templates for building your own.

What gets saved: All registerParam values (frequency, gain, waveform, threshold -- everything), all subscriptions with port mappings (which node feeds which parameter), custom state (object-specific data like sequencer patterns or IO routing mode), and full layout (x, y, width, height, collapsed). Patches are portable -- share a .ewpatch.json file with anyone running the same server and they get your exact configuration.

EW/OBJECTS is a control-rate network, not an audio-rate bus. Understanding what this means will save you from unexpected behavior when patching:

What works well: LFO modulation, parameter sweeps, sequencer triggers, MIDI-speed note events, knob automation, gate/trigger signals, clock pulses. Any signal that changes at roughly human-interaction speed (< 100 changes/sec) will transmit faithfully.

Limitation 1 — Fast transients are lost: Continuous ports dispatch at a maximum of 100 Hz (one value per 10ms). If a parameter changes faster than this — for example, a 1ms attack envelope, an audio-rate FM modulator, or a fast sample-and-hold — only the most recent value in each 10ms window is transmitted. The intermediate peaks and valleys are silently dropped. You will see a ~N DROP indicator in the header bar when this happens.

Limitation 2 — Message ordering is non-deterministic across connections: Unlike Max/MSP or Pd where message fan-out within a logical tick follows a fixed evaluation order, signals arriving from different WebSocket rooms have no guaranteed relative order. The system mitigates this by tick-batching: all signals that arrive within one microtask are sorted deterministically (by room name, then port name) before callbacks fire. This makes evaluation order repeatable within a processing frame, but it is still not equivalent to the strict depth-first ordering of Pd.

Limitation 3 — Network latency is variable: NTP sync establishes a common clock reference across peers, but actual delivery time varies with network conditions. Expect 5–50ms jitter on a LAN, higher over the internet. For tight rhythmic sync, use a shared clock module rather than relying on simultaneous signal arrival.

How the system compensates:

• Ports named trigger, gate, clock, bang, or reset bypass throttling entirely — every value is transmitted immediately with no loss.
• Output ports can be declared with throttle: false to bypass the 10ms window.
• Incoming signals are tick-batched and sorted for deterministic evaluation order within each processing frame.
• Each signal carries a monotonic sequence number for detecting out-of-order delivery.
• Audio-rate DSP (FM synthesis, envelope following, sample-accurate timing) runs locally in each module's AudioContext — use the FM OSC or Genish modules for true audio-rate modulation rather than sending fast signals across the network.

Rule of thumb: If you need it faster than 100 Hz, it should happen inside one module (local DSP), not between modules (network signals). The network is for control. The AudioContext is for audio.