SOURCE separates audio engine, sensor I/O, and API communication into three independent processes connected by OSC/WebSockets

In its Elk hardware deployment, SOURCE runs as three coordinated processes: (1) sushi, a plugin host that runs the sampler engine as a VST plugin and handles all real-time audio rendering; (2) sensei, which reads physical sensors (buttons, faders, display) and translates them into messages; (3) a Python glue app that communicates with Freesound over HTTPS, manages the UI state, and passes messages between sushi and sensei. The processes communicate via OSC (Open Sound Control) and WebSockets, not shared memory. This separation means the audio engine never calls the network: all Freesound download I/O is handled in the glue app (a separate process/thread) and the audio thread is never blocked. The design also makes the audio core independently reusable as a VST plugin on any DAW, with the glue app adapting to the deployment target.

Examples

During a set, the performer presses a button on the Elk BLACKBOARD → sensei sends an OSC message to the glue app → the glue app calls the Freesound API → downloads a sound → sends a WebSocket message to sushi → sushi loads the audio data into the sampler voice. The audio thread was never blocked.

Assessment

Why does SOURCE keep the Freesound API calls out of the audio processing thread? What are the three processes in the Elk deployment and what does each do? Which inter-process protocol (OSC or WebSockets) is used where?