Hub for Expressive Electronic Live Performance
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


HEELP stands for: Hub for Expressive Electronic Live Performance


It has two main goals:

  • Provide a streamlined environment for live performance of computerized music
  • Provide a hub for model electronic instruments that need a translation layer


  • Support for Eigenharp, Soundplane, LinnStrument, Leap Motion, MPE, standard MIDI and standard audio input
  • Full 64-bit support
  • Runs with a GUI as well as headless
  • Scalable UI with sleak and bare-bones vector-graphics
  • Small enough to run on restricted devices like the BeagleBone Black
  • Channel-based mixer with fixed number of sends and busses for clarity
  • Channels can host any number of instrument and effect plugins in series
  • Busses can host any number of effect plugins in series
  • Per-channel input selection with multiple possible sources (ie. each channel has its set of MIDI, controller and audio ports)
  • Plugins and channels can't be changed in real-time, you set up your environment and parametrize it
  • Channels and busses can have custom colors for the background and foreground for easy identification
  • Each channel runs as separate process and has the possibility to run on a different CPU core
  • Centralized clock and tempo handling
  • State capturing of the entire mixer as scenes
  • Program change support for scene and tempo switching
  • Automatic capturing of all plugin parameter and environment changes in a history with rollback support
  • Multi-track recording of all input and output data of all channels and busses (no individual record enable)
  • Detection of audio activity for automatic splitting of recordings, files can use the name of active scene for easy identification


Having a rigid structure of a list of channels and busses with sends has a series of advantages:

  • It's very easy to understand what is going on during a performance or rehearsal
  • The graph is stable, allowing for completely predictible application behavior
  • Channels can input and output both MIDI and audio
  • There's no master bus in the main process, only aux busses, each channel outputs to the audio interface directly
  • Busses can only receive and output audio
  • Each channel runs as a seperate process:
    • Any channel process (and its plugins) can run on another CPU core, leveraging the parallel nature of modern computers
    • Unstable plugins crash the channel they're part of and don't impact anything else
    • This process uses same audio device callback as the main process
    • All channels and the main process inherently run on the same clock with a 100% predictible relationship
    • The channel audio callback writes the audio buffer to shared memory
    • The channel audio can optionally also directly be output through the audio callback buffer, sending it straight to hardware
    • The channel processes can directly use the system audio and MIDI input ports without having to exchange data with the main process
    • The channel processes can directly use the system audio and MIDI output ports
    • The main process audio callback monitors the finished state of the channel processes
    • The main process collectes the channel audio buffers from shared memory and processes them for the busses
  • The busses are all handled by the main process
  • Non-MIDI controllers are handled by the main process and convert their performance data into MIDI
  • Channels can have non-MIDI controllers as input, receiving appropriate MIDI data from the main process
  • The main process and the channel processes have a private communication channel, this is used for:
    • Propagating application events
    • Sending MIDI data of non-MIDI controllers
    • Sending and receiving channel and plugin state