Exposing a WebSockets and OSC interface lets any UI — web page, hardware controller, script — control an audio plugin at runtime

SOURCE separates the audio engine (a VST plugin) from all UIs by exposing a message-based remote control interface over WebSockets and, optionally, OSC. Any client that can send a JSON or OSC message can control the plugin: a web browser, a Python script, a hardware button, or a Strudel pattern. The action vocabulary is a small set of named commands (e.g. /add_sounds_from_query, /set_sound_parameter, /note_on) with typed arguments. The plugin pushes state back to all connected clients on change. This architecture decouples plugin development from UI development — the HTML/JavaScript UI and the hardware Elk UI both use the same command set. A live coder could send OSC messages from Tidal or SuperCollider to trigger real-time Freesound searches. The pattern generalises: any JUCE plugin can expose this kind of control plane.

Examples

From a Python script: ws.send('{"action": "/add_sounds_from_query", "query": "rain", "num_sounds": 4, "layout_type": 1}') loads 4 rain sounds into a running SOURCE instance without touching the plugin UI.

Assessment

What are two protocols SOURCE uses for remote control, and what determines which a UI uses? Write the message you would send to SOURCE to search for ‘thunder’ sounds and replace currently loaded sounds. What state does the plugin push back to connected clients?